How to Catch C# Exceptions in Visual Studio

How to Catch Exceptions in C# with Visual Studio
Debugging exceptions in C# can be tricky. Ozcode Visual Studio extension adds a set of tools that point you right to the problem.

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.

Forrest Gump – sh*t happens

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.

Visual Studio Exception Settings
The Exception Settings dialog

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).

Uncheck Enable Just My Code

If you’re debugging applications which cross language barriers, such as debugging a Xamarin application, then these are also available in the exceptions settings.

Find root cause - Ozcode

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.

Call Stack

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.

The call stack

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.

Quick Watch

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.

Visual Studio Quick Watch Dialog
A sample exception in the default visualizer
Enhance Visual Studio Debugging - Ozcode

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.

Ozcode Visual Studio Extension exception highlighting
Exception highlighted showing that the variable waiter is the culprit

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.

Ozcode Visual Studio Extension stack trace
The Ozcode stack trace

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.

Ozcode Visual Studio Extension Exceptions Trail
The exception trail

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

A sample search against the object inspector

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

Ozcode Visual Studio Extension

Elevate LINQ debugging with visibility, clarity and insights into your queries.

Time travel to see how your code will execute before you step through it.

Heads-up display gives you powerful visualizations so you can instantly understand what’s happening in your code.

Data tips provide deep insights into your data letting you drill down to any level in a data object.

Ozcode Visual Studio Extension - Free Download


Simon Timms


Keep your code in good shape!

Subscribe to our blog and follow the latest news in the .NET debugging industry

Ready to Dive into Your Prod Code?

Easy debugging with full time-travel data

The Exception

A Quarterly Roundup

Subscribe to our quarterly newsletter and hear all about what’s happening around debugging with Ozcode

Share on facebook
Share on twitter
Share on linkedin
Share on email

Recent Posts

Follow Us

Join Ozcode YouTube Channel

Let’s start debugging, it’s free!

Thanks for downloading the OzCode trial!

You’re well on your way to making C# even sharper.

If your download doesn’t start automatically , please use this direct link.

If you’d like to install OzCode but don’t have
administrative privileges on your machine, please contact us.

Get Started for FREE!

Ozcode Logo

This website uses cookies to ensure you get the best experience on our website.