Forrest Gump is a fantastic movie, perhaps one of the best movies to come out in the 1990s. If you haven’t seen it I’m fine with you stopping reading this post right now and going to watch the movie. At one point in the movie, the titular character is splattered with mud. When asked about it he says “shit happens”.
This is true for our computer programs, too.
When things go wrong we want to handle it as best we can. Ideally, there is some compensating action which can be taken: rolling back a transaction, retrying a request, using a different strategy.
To communicate to a caller that its request has failed, we use a construct called an exception. When throwing an exception, the execution in that block is immediately halted and the exception is raised to the containing block. If that block contains a matching catch, then that handles the exception. If not – the exception continues to bubble up.
First and Second Class Exceptions
When exceptions are first thrown, they are known as first chance exceptions. By default, the Visual Studio debugger won’t break on first chance exceptions if they are handled by a catch block.
If in the catch block the exception is rethrown, then they become known as second chance exceptions and these will cause the debugger to break.
It is possible to have Visual Studio break on first chance exceptions – by changing the exception settings. In this dialog, the exception type can be filtered for limiting you to just breaking on exceptions which are pertinent to your scenario.
It is possible to select all the CLR exception types, but frequently, first chance exceptions are thrown and correctly handled by code in the BCL and will add a great deal of noise. By default, VS breaks only on exceptions in your code.
If a first-chance exception is thrown and caught in library code or BCL code, it’s ignored. In advanced scenarios, you can configure Visual Studio to break on all exceptions in Tools | Debugging | Enable Just My Code (by unchecking).
If you’re debugging applications which cross language barriers, such as debugging a Xamarin application, then these are also available in the exceptions settings.
At the Breakpoint
Once Visual Studio is halted at a breakpoint, you can poke around at the code to your heart’s content. The current values of all the variables can be shown, often by just hovering over the variables with your cursor. For more in-depth investigations you might want to make use of the quick watch dialog or even the watch list.
Another useful dialog is the call stack dialog, which shows where you are inside the application. If you think of each function call as the layers of an onion – the call stack allows you to hop around between the different layers of the onion. At the lowest level is your exception, but the parameters which caused that exception were passed into the method. You can now step back through the call stack and find the code which was actually going wrong.
Another way of looking at the call stack is to look at the stack trace in the exception. This doesn’t allow you to hop around inside of the debugger to look at the context of the exception, but when you’re looking at logs from production – a stack trace is likely all you have.
The lack of detailed information from production is one of the reasons that I’m so big on putting in place extensive logging. It is rare that you’ll find you have too many log statement but if you have too few it makes diagnosing a problem without redeploying with logging changes.
Inside of Visual Studio, you can use the QuickWatch dialog to examine the exception. But as you can see from this screenshot the visualization of the exception is quite primitive. The stack trace can only really be examined by the Text Visualizer which is a generic took and doesn’t have any special support for stack traces.
Ozcode Makes it Better
This is the part of the blog where I get to tell you how much Ozcode helps out with debugging. So let’s get into it!
Before you drill into the exception details you can often figure out the problem by just looking at the editor. Ozcode adds highlighting which points out the line, and often the variable which caused the problem.
If that isn’t enough, the dialog for exploring exceptions in Ozcode shows you a bunch of cool information. First off check out that part in the middle where the stack trace is shown. There is support for syntax highlighting and you can even click on parts of the stack to hop to it.
Next is the exceptions trail located at the top of the dialog. This is a visual representation of the layers of the onion and you can click around in it to quickly examine the various things which have gone wrong.
Finally, the bottom section of the dialog box is almost the same QuickWatch dialog you know and love. Except that this version of it is pumped up with some more Ozcode goodness. There is a search dialog which makes finding that one sneaky value you need
To conclude: While shit may happen, having the tools in place to understand the problems and to debug them make cleaning up much easier.
**Have your own tips on how to handle exceptions? Leave your comment here or tweet @oz_code