First Chance Exceptions
I suspect that most of us have become so used to seeing the message that reads:-
" A first chance exception of type 'System.ApplicationException' occurred in WindowsApplication1.exe "
that it hardly hits our conscious thoughts any more.
But did you ever check out just what this message really means or wonder whether you should or could do anything about it ?
I suppose the first thing you need to know in order to answer those questions is just exactly what a First Chance Exception is. Well, in it's simplest terms it's a mechanism that flags up that there is a possible error condition. The key point here though is that this flagging up takes place in the Debugger and not in the running application itself. (We probably often think of the two as being the same thing, but in fact that's not really the case).
When the Debugger detects an Exception situation it raises a First Chance Exception. In several situations it isn't always desirable for the program to come to a grinding halt each time. And of course, being a skilled developer, you will have built appropriate Try Catch exception handling blocks into the code which will sort the problem anyway! So, depending on the Debugging settings you have laid down (more on this later), the Debugger allows this First Chance Exception to pass and the program continues to run.
Second Chance Exceptions
At this point, where the running program now has to deal with the Exception situation, the application will either handle the Exception or not handle it (your Structured Exception Handling code coming in to play here). If it does handle it, then the application will of course be allowed to proceed and it will happily keep running until the next problem is encountered or the application ends.
If the program fails to deal with the Exception at this point, the Debugger is notified again of this unhandled error situation - and this is now the Second Chance Exception level. Hitting this point will result in the kind of Unhandled Exception Message Box that I know you will have seen many, many times:
An Exceptional Situation - XamlParseException
Although I'd never really given it much thought I guess I'd always assumed that by default the settings in Visual Studio were such that all First Chance Exceptions were allowed through to the program as described above. With some timely assistance from the Microsoft Visual Basic team, I discovered recently that this is not the case. There is one Exception which by default is set to Throw on a First Chance Exception - and that is the XamlParseException.
When I say "by default" I'll have to qualify that slightly. I'm not sure that it is set by default in every kind of installation of Visual Studio 2008, but certainly in the Pro and Express Editions if you have set the Profile to Visual Basic developer settings then this will be the case.
As a result I spent quite a long time struggling with a particular project that had to deal with many situations where the Xaml at certain points in time was not valid and so would not parse. Even though I had built in a Try Catch block for this Exception, the program would never reach that exception handler because the Debugger would throw the Exception at the first chance stage.
The route to finding this setting in the IDE is as follows:
Select Debug > Exceptions
then in the Window that appears, choose "Common language Runtime Exceptions" and expand the list.
Navigate down the list until you reach "System.Windows.Markup".
Next click on the plus symbol to show the Exceptions in this class.
(Alternatively you can click the "Find..." button and enter the name of the Exception).
You can see in the screenshot below that the "Thrown" checkbox is checked:
which is of course the reason why my project was stopping in Debug mode whenever it first hit a XamlParseException.
If you want your code to be allowed to handle this kind of Exception (as I did) then of course you just need to uncheck that box.
I did a quick sweep of all the settings for all Exceptions and that XamlParseException seems to be the only one that is checked by default. But if you should come across a similar puzzling situation yourself in the future, you should probably think of those Exception settings as one of the places you should first look.