I have a project that runs perfect under windows xp.
Now I have tried to run it under Windows 7 and got there a lot of exceptions under Immediate window.
A first chance exception of type 'System.ArgumentNullException' occurred in Microsoft.VisualBasic.dll
A first chance exception of type 'System.IO.FileNotFoundException' occurred in LP_Wizard.exe
A first chance exception of type 'System.ArgumentException' occurred in LP_Wizard.exe
A first chance exception of type 'System.NullReferenceException' occurred in LP_Wizard.exe
A first chance exception of type 'System.InvalidCastException' occurred in Microsoft.VisualBasic.dll
A first chance exception of type 'System.ArgumentNullException' occurred in Microsoft.VisualBasic.dll
A first chance exception of type 'System.IO.FileNotFoundException' occurred in LP_Wizard.exe
A first chance exception of type 'System.InvalidCastException' occurred in Microsoft.VisualBasic.dll
A first chance exception of type 'System.ArgumentNullException' occurred in Microsoft.VisualBasic.dll
A first chance exception of type 'System.IO.FileNotFoundException' occurred in LP_Wizard.exe
A first chance exception of type 'System.ArgumentNullException' occurred in Microsoft.VisualBasic.dll
A first chance exception of type 'System.IO.FileNotFoundException' occurred in LP_Wizard.exe
Any idea what wrong with that Microsoft.VisualBasic.dll in windows 7 and how i correct that problem ?
Thanks a lot for help .
If you want to pinpoint where the exceptions are occurring, you can select the Debug->Exceptions menu item, and in the dialog that appears, check the first checkbox for "Common Language Runtime Exceptions". This will make the debugger break as soon as an exception occurs instead of only breaking on unhandled exceptions.
This is also one reason why it is generally a bad idea to catch generic exceptions unless you are clearly logging the information caught.
What is happening is the debugger can "see" exceptions as soon as they are raised (hence the "first chance") before any catch block is hit. Any exception which is not handled by a catch block is considered a "second chance" exception and will break normally.
If these exceptions aren't stopping the running of your application because they are unhandled then you are probably OK. Most of the time the exception is handled by code and this isn't a problem. The output is simply Visual Studio letting you know the exceptions were raised.
See the "Avoiding first chance exception messages when the exception is safely handled" question for some methods to reduce this if there are too many to ignore.
Are your in the debugger? Are these exceptions your program is handling? If so you need to find a setting that tells VB to supress warning you of handled exceptions. Maybey this was set when installed on XP but not when you installed on W7. See if this helps:
http://www.helixoft.com/blog/archives/24
Related
I notices some code that made me think the Exception function call was optional? E.g., do these two lines perform the same function?
throw Exception('oops!');
throw 'oops!'
No.
The former, throw Exception('oops!');, creates a new Exception object using the Exception constructor, then throws that object.
It can be caught by try { ... } on Exception catch (e) { ... }.
The latter, throw 'oops!'; throws the string object.
It can be caught by try { ... } on String catch (e) { ... }.
Generally, you shouldn't be doing either.
If someone made an error, something that would have been nice to catch at compile-time and reject the program, but which happens to not be that easy to detect, throw an Error (preferably some suitable subclass of Error).
Errors are not intended to be caught, but to make the program fail visibly. Some frameworks do catch errors and log them instead. They're typically able to restart the code which failed and carry on, without needing to understand why.
If your code hit some exceptional situation which the caller should be made aware of (and which prevents just continuing), throw a specific subclass of Exception, one which contains the information the caller needs to programmatically handle that situation. Document that the code throws this particular exception. It's really a different kind of return value more than it's an error report. Exceptions are intended to be caught and handled. Not handling an exception is, itself, an error (which is why it's OK for an uncaught exception to also make the program fail visibly).
If you're debugging, by all means throw "WAT!"; all you want. Just remove it before you release the code.
I am using CTFontManagerRegisterGraphicsFont to register CGFont loaded at runtime from various sources (files, memory, ..), but some fonts raises an Exception with the following message:
Exception: "*** -[__NSPlaceholderArray initWithObjects:count:]: attempt to insert nil object from objects[0]"
an alternative to CTFontManagerRegisterGraphicsFont is CTFontManagerRegisterFontsForURL:
using this function I did not have any exception raised.
My Questions:
What is the cause of this behavior difference
How to catch & discard the exception raised by CTFontManagerRegisterGraphicsFont
Is there any thing to be done before calling CTFontManagerRegisterGraphicsFont to prevent the exception.
What .persistent scope mean for 2nd parameter in CTFontManagerRegisterFontsForURL.
I'm using Error Handling in WorkFusion.
Is there a way to see the error message in the catch block i.e. exception occurred block.
How about using:
<log>exception_msg_var</log>
or
println exception_msg_var
exporting exceptions to datastore?
To get the error message in RPA Express, you can keep the code outside of exception handling and then, the software will through error message on its' own. Once you get the type of error (by running the bot once), you can put the solution in catch block by keeping the code inside exceptional handling feature.
Using XCTest, a test does the following:
XCTAssertThrowsSpecificNamed([does something that breaks], NSException, NSInvalidArgumentException);
I don't want the debugger to stop on the NSException that I know will occur but I want it to still stop on other exceptions that might occur.
Basically we don't have a choice. I still consider it an xCode bug because you already told xCode an exception will be thrown, and what exception it will be. Why provide XCTAssertThrows if it's an exception you're not "expecting"?
Obviously it's for exceptions you are expecting, which #nhgrif argues should be an error, not an exception. Might be a good point, but i do want my program to crash if this case ever happens, because I can't handle it.
So the real question is more why not disable the debugger on that exception only? Probably because they haven't gotten around to it. I'd suggest opening a bug/feature request with Apple. I'd love for someone to contradict me on this (please comment!) but until then, I'll live with this issue (disable debugger when running all my tests).
--> https://stackoverflow.com/a/22393643/1701430
"Why does the test stop when the execution is thrown?"
Because you have a breakpoint, which stops execution.
"Why, after removing the breakpoint, does my application crash when the exception is thrown?"
Because you have an unhandled exception. Unhandled exceptions cause your program to crash.
"How can I handle an exception so it won't crash my program?"
The easy answer to this question is to simply NOT throw an exception. In other programming languages, like Java, this is perfectly standard. But in Objective-C, we don't really do exceptions. In Objective-C, exceptions should be saved for TRULY exceptional behavior.
With that said, and a strong suggestion for you to find another way to handle whatever it is you're trying to handle, this is how you handle an exception in Objective-C:
#try {
// code that could throw an exception
}
#catch (NSException *e) {
// handle the exception...
}
#finally {
// post try-catch code, executed every time
}
does file related functions throw an exception when it fails OR just return false.
Coz even if I use it in try-catch, there is no point in catching an exception if fopen/fwrite does not throw it at all…
Return Values
Returns a file pointer resource on success, or FALSE on error.
Errors/Exceptions
If the open fails, an error of level E_WARNING is generated. You may use # to suppress this warning.
Check documentation. you can throw custom exception if you want to.