“I am trying to debug, but this stupid exception keeps happening”. I have seen that situation play out many times over the years. You are trying to exercise your code, but the same spot keeps throwing an exception. This doesn’t impact your functionality, but it’s an annoyance.
Sometimes it takes a while for the frustration to hit a peak, but when it does you are besides yourself. There is functionality in Visual Studio to help you out, but before that let’s talk philosophy.
There are many schools of thought with regards to developing code. On one side, if your tests (unit,integration,etc.) are not passing then you cannot check-in. This would imply that if the code base you are working on is throwing exceptions, then you cannot check-in until it is fixed. Under this philosophy, everything stops until the code is in good working order.
On the other side, you have blinders on and you only focus on getting your code to work. In this scenario it is OK to skip over some exceptions, because it is someone else’s problem. I don’t have to preach about the issue with the “someone else’s” problem, but that does not help your team.
The scenario that I left out is less philosophy and more practice. Sometimes in the code there are bugs that are OK to not be fixed. This could be for many reasons, like priority or planned obsolescence.
I alway recommend that my team members use a little known set of toggles in Visual Studio called Exception Settings. Exception settings allow you to have a first crack at code (first chance) that is about to throw an exception.
Without having this functionality turned on, the code will throw and you may not be able to proceed. The first chance exceptions would allow you to move the stack pointer to a different line that would function normally and continue. This is very powerful when you are trying to figure out where an exception is coming from and the state of the system (threads, call stack, variables, etc…) when it happens.
I have been in situations where it was OK and even expected for code to throw, but it I don’t want to have to view it each time. In this case, Visual Studio allows you to deselect the exceptions that you don’t care about. You can see below that I chosen to to break on all exceptions except for Microsft.JScript.JScriptException.
To use this functionality you have to set these toggles in advance of starting your application. Consider this, you are running a long process, but you got interrupted by an exception that you did not expect, but you do not care if it throws. In that case, you have the option to turn off first chance exceptions for the exception type for all future executions. You need only deselect the “Break when this exception type is thrown” checkbox.
I the case above, the exception is expected as part of the SSPI authentication process so I can ignore this exception.
It doesn’t matter which school of thought you or your team subscribes to, but the ability to toggle first chance exceptions is an important hammer to have in your toolbox.
Side Bar: I can’t recommend enough to turn on this functionality. It has helped me catch a lot of bugs before they got into the wild. Hope this helps, cheers.