One of the best things I love about consulting is how much I learn from my clients.
I have been in out in Salt Lake City for the last few weeks working on a WCF SOA project for a client and have been stepping through lots of code. And I'm not just talking about regular .NET code either- I'm talking two instances of Visual Studio 2005 up and running, one exercising a test harness/unit test and the other hosting a WCF service. I love the ability to step through a client, watch the call cross the process boundary and step into the service code. Visual Studio 2005 is truly a marvel of an IDE!
One of the things I learned from the lead .NET developer (Sam "Samwise" Walker) this week is that VS 2005 supports the ability to control how the debugger interacts with exceptions. I have always debugged as follows:
1. Step through the code
2. If an exception is thrown, the debugger chokes at the top-most level in the call chain
3. I then trace the exception back to the original site
This approach is ardous because by default the debugger will capture unhandled exceptions, but since exceptions bubble up to the top of the call stack, you are always left dealing with the outer exception.
The solution is to set VS 2005 up to intercept exceptions as they are thrown, the first time an exception is thrown. This is contrary to the default behavior where the debugger will only catch the last unhandled exception as it winds it's way up the call stack.
To enable this feature, in VS 2005, click Ctrl + Alt + E. An Exceptions window will appear. You will notice that for "Common Language Runtime Exceptions", the right-most column, "User Unhandled" is checked. This is the default behavior. Click the checkbox next to "Common Language Runtime Exceptions" labeled "Thrown". From this point forward, you will capture the very first exception as it is initially thrown.
Hopefully, this tip will save you some time in your next debugging session.
Thanks Sam!