I'm getting near my 20th anniversary in the tech industry. During the years, I have seen almost every anti-pattern when dealing with exceptions (and made the mistakes personally as well). This post contains a collection of my best practices when dealing with exceptions in C#.

Don't re-throw exceptions

I see this over an over again. People are confused that the original stack trace "magically" disappear in their error handling. This is most often caused by re-throwing exceptions rather than throwing the original exception. Let's look at an example where we have a nestedtry/catch:

try{try{// Call some other code thay may cause the SpecificException}catch(SpecificExceptionspecificException){log.LogError(specificException,"Specific error");}// Call some other code}catch(Exceptionexception){log.LogError(exception,"General erro");}

As you probably already figured out, the innertry/catch catches, logs, and swallow the exception. To throw theSpecificException for the globalcatch block to handle it, you need to throw it up the stack. You can either do this:

catch(SpecificExceptionspecificException){// ...throwspecificException;}

Or this:

catch(SpecificExceptionspecificException){// ...throw;}

The main difference here is that the first example re-throw theSpecificException which causes the stack trace of the original exception to reset while the second example simply retain all of the details of the orignal exception. You almost always want to use the second example.

Decorate exceptions

I see this used way to rarely. All exceptions extendException, which has aData dictionary. The dictionary can be used to include additional information about an error. Whether or not this information is visible in your log depends on what logging framework and storage you are using. For elmah.io,Data entries are visible in the Data tab within elmah.io.

To include information in theData dictionary, add key/value pairs:

varexception=newException("En error happened");exception.Data.Add("user",Thread.CurrentPrincipal.Identity.Name);throwexception;

In the example, I add a key nameduser with a potential username stored on the thread.

You can decorate exceptions generated by external code too. Add atry/catch:

try{service.SomeCall();}catch(Exceptione){e.Data.Add("user",Thread.CurrentPrincipal.Identity.Name);throw;}

The code catches any exceptions thrown by theSomeCall method and includes a username on the exception. By adding thethrow keyword to thecatch block, the original exception is thrown further up the stack.

Catch the more specific exceptions first

You know you have code similar to this:

try{File.WriteAllText(path,contents);}catch(Exceptione){logger.Error(e);}

Simply catchingException and logging it to your preferred logging framework is quick to implement and get the job done. Most libraries available in .NET can throw a range of different exceptions, and you might even have a similar pattern in your code-base. Catching multiple exceptions ranging from the most to the least specific error is a great way to differentiate how you want to continue on each type.

In the following example, I'm explicit about which exceptions to expect and how to deal with each exception type:

try{File.WriteAllText(path,contents);}catch(ArgumentExceptionae){Message.Show("Invalid path");}catch(DirectoryNotFoundExceptiondnfe){Message.Show("Directory not found");}catch(Exceptione){varsupportId=Guid.NewGuid();e.Data.Add("Support id",supportId);logger.Error(e);Message.Show($"Please contact support with id:{supportId}");}

By catchingArgumentException andDirectoryNotFoundException before catching the genericException, I can show a specialized message to the user. In these scenarios, I don't log the exception since the user can quickly fix the errors. In the case of anException, I generate a support id, log the error (using decorators as shown in the previous section) and show a message to the user.

Please notice that while the code above serves the purpose of explaining exception order, it is a bad practice to implement control flow using exception like this. Which is a perfect introduction to the next best practice:

Avoid exceptions

It may sound obvious to avoid exceptions. But many methods that throw an exception can be avoided by defensive programming.

One of the most common exceptions isNullReferenceException. In some cases, you may want to allow null but forget to check for null. Here is an example that throws aNullReferenceException:

Addressa=null;varcity=a.City;

Accessinga throws an exception but play along and imagine thata is provided as a parameter.

In case you want to allow a city with anull value, you can avoid the exception by using the null-conditional operator:

Addressa=null;varcity=a?.City;

By appending? when accessinga, C# automatically handles the scenario where the address isnull. In this case, thecity variable will get the valuenull.

Another common example of exceptions is when parsing numbers or booleans. The following example will throw aFormatException:

vari=int.Parse("invalid");

Theinvalid string cannot be parsed as an integer. Rather than including atry/catch,int provides a fancy method that you probably already used 1,000 times:

if(int.TryParse("invalid",outinti)){}

In caseinvalid can be parsed as anint, theTryParse returnstrue and put the parsed value in thei variable. Another exception avoided.

Create custom exceptions

It's funny to think back on my years as a Java programmer (back when .NET was in beta). We created custom exceptions for everything. Maybe it was because of the more explicit exception implementation in Java, but it's a pattern that I don't see repeated that often in .NET and C#. By creating a custom exception, you have much better possibilities of catching specific exceptions, as already shown. You can decorate your exception with custom variables without having to worry if your logger supports theData dictionary:

publicclassMyVerySpecializedException:Exception{publicMyVerySpecializedException():base(){}publicMyVerySpecializedException(stringmessage):base(message){}publicMyVerySpecializedException(stringmessage,Exceptioninner):base(message,inner){}publicintStatus{get;set;}}

TheMyVerySpecializedException class (maybe not a class name that you should re-use :D) implements three constructors that every exception class should have. Also, I have added aStatus property as an example of additional data. This will make it possible to write code like this:

try{service.SomeCall();}catch(MyVerySpecializedExceptione)when(e.Status==500){// Do something specific for Status 500}catch(MyVerySpecializedExceptionex){// Do something general}

Using thewhen keyword, I can catch aMyVerySpecializedException when the value of theStatus property is500. All other scenarios will end up in the general catch ofMyVerySpecializedException.

Log exceptions

This seem so obvious. But I have seen too much code failing in the subsequent lines when using this pattern:

try{service.SomeCall();}catch{// Ignored}

Logging both uncaught and catched exceptions is the least you can do for your users. Nothing is worse than users contacting your support, and you had no idea that errors had been introduced and what happened. Logging will help you with that.

There are several great logging frameworks out there like NLog and Serilog. If you are an ASP.NET (Core) web developer, logging uncaught exceptions can be done automatically using elmah.io or one of the other tools available out there.

Would your users appreciate fewer errors?

elmah.io is the easy error logging and uptime monitoring service for .NET. Take back control of your errors with support for all .NET web and logging frameworks.

➡️Error Monitoring for .NET Web Applications ⬅️

This article first appeared on the elmah.io blog athttps://blog.elmah.io/csharp-exception-handling-best-practices/