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.
Related
For my simple code It seems that the return statement is not needed after the error statement.
Does that mean the function would be early terminated once error is thrown?
If the above is true, what if i do want to process with the rest of function even after an error is thrown. For example, i can still compute c = a - b in my function.
Yes, the error terminates the program.
As suggested by Hoki, use a warning instead.
Note: Your function will throw anyway, if only modifying the code to use warning. This is because the return variable c is not assigned before after the if-statement.
I was trying to find a way in Flutter/Dart to mark a function that may throw an exception during its execution. After some time searching in the documentation and Google I did not find any way of doing this.
In other language, for example Swift, Java, Kotlin, etc I know we have such mechanism.
Sample code in Swift is:
func doSomething() throws { ... }
Does anyone know if this exists in Dart?
I think it will be useful.
If it does not exist due to Dart language desing then maybe anyone can explain the reason behind this decision.
Thanks in advance!
There is no way in Dart to mark a function as potentially throwing.
All functions should be assumed to potentially throw (if for no other reason, then because of an out-of-memory or stack-overflow situation).
If you look at Swift, the throws is about exceptions, not errors. Dart does not distinguish the two, you can throw anything. Swift has put itself in a place between Java ("have to declare all thrown exceptions") and Dart or C# ("Can't declare exceptions").
Marking a function as "throwing" doesn't help the compiler in any way because it has to assume that all other functions might too. The Swift approach is there to ensure that distinctively marked exceptions are not ignored. Unless you want to, then you can try! them and turn the exception into an error.
If a function does throw as part of normal usage, you should document it in the function's documentation.
Dart also have the issue of function types. Is a function from int to int the same type as another function from int to int if the latter can throw? Separating function types into throwing and non-throwing get complicated quickly. Even more so if you want to specify what it throws. It's not impossible, but it's one more complication.
The one thing that you will get with the Dart null safety update (currently being worked on), is a way to state that a function always throws. If you make the return type Never in null-safe code, then the type system will prevent you from returning any value, and since a function call must end by either returning a value or throwing, a call to a function with return type Never can only end by throwing.
The following line of code causes my program to break in a very strange way...
id foo = (id)0xbfffe8d0;
Yet, this is no problem:
int foo = (int)(id)0xbfffe8d0;
And even this is no problem:
int magicAddr = 0xbfffe8d0;
id foo = (id)magicAddr;
W. T. F. ?
Just inserting that line of code inside a particular init method causes my iteration through an array to fail with "NSGenericException: Collection was mutated while being enumerated". Commenting the line out causes the exception not to happen. This code is single-threaded. The behavior is deterministic and has consistently reproduced over and over again and consistently non-reproduced when I comment the line out. "foo" is a made-up variable and is never referenced again. No other code refers to "foo".
Does that line have a side-effect? Does casting a number to an (id) have some side-effect?
More details on what I was doing:
I ran NSLog(#"self=%p, super=%p", self, super) and it printed out "self=0xa83dc50, super=0xbfffe8d0", leading me to ask this question
I have _NO_IDEA_ what that 0xbfffe8d0 value is or means.
The line I pasted is inside a method init2 for a class that has a reference to the NSEnumerator over the collection which throws the Exception. The class does NOT mutate the collection or even have a reference to the collection.
The exact code: (removed, not relevant or interesting)
OK, so I still can't explain the behavior above. I can't explain why a 4-byte int on the stack is ok, but a 4-byte "id" is crashville. But I ran this code a few hundred times putting all manor of random crap in, and I was able to trigger crashes with other values and statements. Always deterministic, but no clear or explainable pattern for stuff that crashed vs stuff that didn't. Bizzare stuff, but not the ultimate issue.
The real issue? The collection was from [NSThread callStackSymbols]. That returns _NSCallStackArray. That's where the real Zebra lives. There's something funky about that pseudo-collection, but I couldn't tell you what exactly.
The fix?
[NSArray arrayWithArray: [NSThread callStackSymbols]]
With the fix, no combination of random crap in my code will trigger the enumeration crash. So beware. If you plan to return the call stack symbols and treat them as an array, MAKE A COPY.
The lesson? If you call [NSThread callStackSymbols] and want to treat the result like an array, MAKE A COPY and get a real array. Else, .... "there be dragons" !!
No. id is a typedef for a pointer type, and assigning to a pointer has no side effects. You have some other bug in your code somewhere else, it's impossible to say without seeing more code.
0xbfffe8d0 is a pointer to an address in your stack. When compiled without optimizations, the assignment does write the value 0xbffe8d0 into your stack, but that value then never gets read anywhere. So it does have the effect of (a) increasing that function's stack frame size by 4 bytes and (b) changing the size of the function's code and offsetting all of the subsequent code. Most likely these changes are causing the bug elsewhere in your program to appear or not appear.
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).
What's the difference between these two?
MsiInstallProduct and Installer.InstallProduct. From what I've read, the only difference is that the first returns an int that will dictate if the installation succeeded or not.
I am currently using DTF (WiX) to call Installer.InstallProduct. The problem is, this function has a return type of void.
Question:
How can I determine if the installation succeeded or not when calling Installer.InstallProduct via DTF?
As you noticed, MsiInstallProduct simply returns error or success with no further information. Installer.InstallProduct returns nothing. DTF returns nothing.
Why the difference? MsiInstallProduct is old school C/C++ where you return error codes. The others are new school where instead you raise exceptions. Your code then catches the exception to know that there was a problem.