this throws an exception, when the field does not exist:
reader.IsDbNull(reader.GetOrdinal("FieldName")) => bang
Why not return -1 ?
I'll try to guess here.
The common pattern for this method is to call GetOrdinal for column name and then call GetXXX() methods with given ordinal which is faster than do a search by column's name every time.
Therefore in case of exception here we fail fast and we can't ignore it. Wihtout exception we will try to find a column that doesn't exist and then try to find a field by given ordinal (without checking for -1 which is very easy to omit in this case) and only here we will realise that something went wrong few steps before (may be even too many steps before).
Related
I encountered a problem, which is consistent with the problem on this link.
-> Optaplanner unable to remove ConstraintMatch
Exception:
org.optaplanner.core.api.score.constraint.ConstraintMatchTotal.removeConstraintMatch
I debugged, and both hashCode and Equals were rewritten, but errors were still reported.
Rule:
rule "scheduleFullTimeLimit"
when
$shiftList: ArrayList() from collect (
StaffAssignment(
shiftType != null
)
)
then
scoreHolder.addSoftConstraintMatch(kcontext, -1);
end
I used collect in my rules.
Is this a bug?
Beg your help
I am afraid that the problem here will be with the ArrayList. ArrayList's hashCode() will change with every change to the collection. Therefore, you will get the exact message you're getting - OptaPlanner is trying to undo something which does not exist.
You'll have to figure out how to do whatever you're doing without the ArrayList. At the very least, don't let the ArrayList be the final thing in the rule, because I believe that is what lands it in the constraint matches in the first place.
I was working on the databricks log analyzer app with spark and scala.
In the object ApacheAccessLog they throw a RuntimeException if the log line doesn't respect the set pattern.
log match {
case PATTERN(ipAddress, clientIdentd, userId, dateTime, method, endpoint, protocol, responseCode, contentSize)
=> ApacheAccessLog(ipAddress, clientIdentd, userId, dateTime, method, endpoint, protocol, responseCode.toInt,
contentSize.toLong)
case _ => throw new RuntimeException(s"""Cannot parse log line: $log""")
}
I would like that someone explain to me why i would throw a RuntimeException and break my program just because one log line doesn't respect my pattern? Isn't better to just skip that line so that the program will continue processing only the lines that respect the pattern?
Also i will be happy if you suggest a better idea as a workarround.
Look, it's just an example, there is no philosophy in there :) You are right, more permissive solution would just skip that line, but sometimes you may want rather get an exception than miss something.
Why they wrote code that way? Maybe they expect every line match pattern, maybe something else, we will never know and it doesn't matter. But it is good that you think about the consequences of design decisions and alternative solutions
I just updated my old project to use version 4.13.0 and there was a lot of exception validation with ComparisonMode.Substring, but ComparisonMode.Substring does not exist in the newest version. I found this that explains that:
As a result of this, I decided that as of version 2.1, the ComparisonMode is obsolete and any assertions against the exception message is treated as a case-insensitive wildcard match.
But now I get loads of failed tests with:
Expected exception message to match the equivalent of "Value of
argument 'PeriodEnd' must be greater than '01.01.0001'", but "Value
of argument 'PeriodEnd' must be greater than '01.01.0001'. Value is
'01.01.0001'.
Parameter name: PeriodEnd" does not.
string I assert with
Value of argument 'PeriodEnd' must be greater than '01.01.0001'
The one it expects
Value of argument 'PeriodEnd' must be greater than '01.01.0001'. Value is '01.01.0001'.
Parameter name: PeriodEnd
But from the "patch notes" from before it seems that it should be a wildcard, and the string I assert from is a substring of the one it really is, so why does it fail?
You still need to add the wildcard characters to the call to WithMessage, just like you did when ComparisonMode.Wildcard still existed. The rationale is explained in this post:
If you need to verify that a certain string value or exception message matches the expectation, never verify the exact message. Use wildcards to verify the specific parts that are relevant to verify that the behavior meets the expectation. It will save from unexpectingly failing tests if you decide to refine the text involved.
I have a function in matlab calculating something. Within that function I open another function to calculate something for it.
Now in this second function I have some case where I just want to stop everything if some certain condition is true (so I want to end both functions)
I don't want an error message or anything; Is there a command for that?
If I just type in error I get some notice in red with a message such as:
error: Invalid call to error. Correct usage is:
-- Built-in Function: error (TEMPLATE, ...)
-- Built-in Function: error (ID, TEMPLATE, ...)
error: called from:
error: /usr/share/octave/3.8.1/m/help/print_usage.m at line 89, column 5
>>>error: /home/john/wpq.m at line 75, column 4
error: /home/john/test.m at line 23, column 21
if I write error('blabla') I still get:
>>>error: blabla
error: called from:
error: /home/john/wpq.m at line 75, column 4
error: /home/john/test.m at line 23, column 21
I would like to get no output because I can write one line above already something like disp('the test on this number failed').
You could try placing a try/catch block in your main function to expect the condition under which you want code execution to stop.
I don't believe that there is any one command that allows code to stop execution from a function within a function.
There are a number of ways of doing what you want. Typically error is only meant to be used for things that actually is errors. You do for example get an "index out of bounds" error if you try to access an element outside the array. In case what happens is an error you should send an error message to inform users about what happens and highlight that this is an error. However, in case you only want this particular calculation to end and not the program I would instead recommend try-catch and printing the error message in catch.
In case this is normal termination (or if only a particular function terminates unnormally and this is expected for some input) you can either use a termination condition (function [out,success] = myFun(in)) or try-catch. Both are accepted, though I use to prefer the termination condition approach for normal termination and try-catch for unnormal termination (of functions). Unnormal termination can for example be when a function have to be terminated before all output variables are calculated. I use to prefer to have an exception thrown instead of a function returning invalid values (but a c-programmer would probably argue differently).
For the record, there is a return-statement in Matlab which terminates a particular function.
It is hard to recommend a particular approach without knowing the situation you are in, but this text would give you some different options to be choose between. Know that error handling seldom have standard approaches which can be said to be "right". It is often up to the programmer to decide what is suitable and that is typically a part of the design.
Good luck!
il.Emit(OpCodes.Callvirt, _compactBinaryReader_ReadObject);
this function is called and at a special condition a return value of 'null' is provided.
if that value is null i have to take a decision whether to jump on to a label or not
using after the method call
il.Emit(OpCodes.Dup);
il.Emit(OpCodes.Brfalse_S, DECISION);
gives me an exception "JIT Compiler encountered an internal limitation." when i call that function, the code builds correctly though.
tried OpCodes.Brfalse too.
what am i doing wrong ?
Found reasonS to the above problem,
one thing which should be understood that when an exception of
'CLR: Verification for Runtime Code Generation'
is thrown it means the code written is not in the correct format and when it is evaluated by the assembler it does not accept the written code, problem is usually because of stacks having extra values or less.
"JIT Compiler encountered an internal limitation." is thrown when at runtime it was expecting something else we provide something else in value or when stack has something else when something else was required.
In short, the later exception is thrown at runtime and the other is thrown when pre Run conditions are not met.
anyways i found the reason, i had some values still present on stack that i did not pop if Condition was met, so the POP OpCode did the trick, and by the way for me the Dup OpCode never worked out, it always pushes a null value on stack rather than duplicating the top most value.