An app should throw exceptions when something exceptional happens. However, apps and APIs should be designed so that under normal use, exceptions do not occur. Exceptions are a good way to tell the debugger, or logging tools that something went wrong. When debugging with the break on all exceptions feature is turned on, it is possible to get information about what went wrong immediately. However, by default, Visual Studio projects don’t have this feature turned on. This is a guide on how to turn on, and use this feature.

Exceptions carry a stack trace with them, so they can provide a wealth of information about where the exception arose from and why. Breaking in the debugger on all exceptions can help to diagnose issues at the source. This guide is aimed at Visual Studio on Windows, but the feature is very similar on Visual Studio for Mac. This feature has existed for most of the life of Visual Studio so it should work on any Windows version.

Note: let’s not get too caught up on the semantics of “apps and APIs should be designed so that under normal use, exceptions do not occur”. It just means that if all is well in the app, exceptions shouldn’t be thrown.

Exception Handling

You should acquaint yourself with Exception handling in C# first and foremost. Microsoft has a best practices guide that is also very useful. As a general rule, it is a good idea to always debug with break on all exceptions turned on. This means that if anything in the app goes wrong, there will be an alert immediately at the point of failure. There is a general programming principle behind this called fail fast. However, in order to use break on all exceptions, the app’s code should never throw exceptions under normal circumstances. If the code does so, the debugging flow will be interrupted. Also, Exceptions are costly operations.

Turn it On

On Windows, Debug -> Windows -> Exceptions Settings

ExceptionSettings

The window will will appear like so. The Common Language Runtime Exceptions is the section we will be interested in for C# and .NET.

ExceptionSettings 2.png

Note: Mac instructions will be added in future

Clicking this twice will result in a tick for all Exception types. If this is is ticked, this means that Break on All Exceptions is turned on. The debugger will always break whenever an exception is thrown in your code. It will look like this when the node is expanded.

ExceptionSettings 3

Example

Break On All Exceptions turned Off

In this example, the feature is not turned on. The app will execute and complete without the debugger displaying any information about the exception thrown. This essentially means that Exception information will be ignored by the debugger.

class Program
{
    static void Main(string[] args)
    {
        try
        {
            Test();
        }
        catch(Exception ex)
        {
        }

        Console.Write("The process completed");
        Console.ReadLine();
    }

    public static void Test()
    {
        throw new Exception("Break here please");
    }
}

Note: production code should always log exceptions in some way

Exceptions 1The output

Exceptions 2

Break On All Exceptions turned On

If we turn break on all exceptions on and rerun the example, this is what will happen. The debugger will stop at the source of the Exception, and you will be able to wind back the Call Stack. If the app is designed well, it is possible to debug like this in all scenarios.

Exceptions 3.png

More Information

  • If there are too many exceptions being thrown, it is sometimes still possible to turn on breaking for most Exception types. Just turn off the ones that are causing issues with the checkbox.
  • It’s normally preferable to debug with “Just My Code” turned on. This is the default setting in Visual Studio

jmc

This means that Exceptions will only be caught in the debugger when they are thrown by the code in the project being debugged, or the underlying code is throwing an Exception that is not being suppressed by a try/catch. Turning this off is often useful for getting details about Exceptions in the underlying code, but it usually ends up disrupting the normal debugging experience.

  • The Exceptions settings are not stored in the csproj file. They are a user setting and are usually ignored by Git. Therefore, the settings are usually wiped out when a repo is freshly cloned, or a Git clean is performed. It’s importantly to communicate with your team members about Exception handling and debugging thereof.

Conclusion

Take Exception handling in to account when designing code. If done well, it will make debugging easier. If done poorly, it will slow down your application and make it difficult to find the source of issues. If turning on break on all exceptions is possible, it will allow the source of exceptions to be found immediately rather than trace back what happened after the fact.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s