.NET Core - Handling Exceptions

What is an exception?

 

An exception is thrown when your code reaches a state that was not planned at the time of execution. It may happen mainly due to unexpected input or due to bad quality code.

• Read more about exceptions

Benefits of handling exceptions

 

Preventing your application from crashing is one of the various benefits of handling exceptions. Some others are as follows:

• Present the end-user with a more detailed message about what happened;
• Improve the security of your system, not displaying any sensitive data to your end-users;
• Avoid crashes, leaving your clients upset;
• Logging details about what caused the exception.

Why handle exceptions?

 

It is a software development good practice to prevent exceptions from being thrown to your end-users, but there are more reasons for this.

• Create planned exception handlers, based on the exception type;
• Have different process flows, keeping the data integrity;
• More accurate logging;
• Protect your code, not letting sensitive data to be exposed.

Exceptions hierarchy

 

The compiler is going to hit in the first exception handler which satisfies the exception thrown, so we must pay attention to the exception hierarchy and the exception handlers' order. Otherwise, we may have a result different than expected.

 

As every exception is derived from System.Exception, the default exception handler must be the last one so it is only going to be hit if none of the exception handlers satisfies the condition. 

• Read more about System.Exception

Sample of exceptions

 

For the samples below, we are going to use a .NET Core Console Application.

 

Custom Exception

 

Creating the custom exception

 

This is a very basic custom exception handler. You may improve it as far as you wish. Note that it must inherit from the Exception.

public class CustomException : Exception
{
    public CustomException(): base("This is a custom exception")
    {
    }
}

Exception handler

public static void CustomException() {
 try {
  throw new CustomException();
 } catch (CustomException ex) //must comes first
 {
  Console.WriteLine(ex.Message);
 } catch (Exception ex) {
  Console.WriteLine(ex.Message);
 }
}

Note the exceptions' order, if you change their order, the order in which the first exception is going to hit will also change.

 

ArithmeticException

int division = 0;

try {
 var throwException = 15 / division;
} catch (ArithmeticException ex) //must comes first
{

 Console.WriteLine(ex.Message);
} catch (Exception ex) {

 Console.WriteLine(ex.Message);
}

The above point applies to all the below-mentioned exception handlers too.

 

NullReferenceException

List < int > nullIntegerList = null;
try {
 var throwException = nullIntegerList.Count;
} catch (NullReferenceException ex) //must comes first
{
 Console.WriteLine(ex.Message);
} catch (Exception ex) {
 Console.WriteLine(ex.Message);
}

IndexOutOfRangeException

int[] sampleArray = new int[3] {
 1,
 2,
 3
};
try {
 var throwException = sampleArray[3];
} catch (IndexOutOfRangeException ex) //must comes first
{
 Console.WriteLine(ex.Message);
} catch (Exception ex) {
 Console.WriteLine(ex.Message);
}

FileNotFoundException

try {
 var throwException = File.Open(@ "C:\notExistentFile.jpg", FileMode.Open);
} catch (FileNotFoundException ex) //must comes first
{
 Console.WriteLine(ex.Message);
} catch (Exception ex) {
 Console.WriteLine(ex.Message);
}

Congratulations. You have seen a very important way to protect your code and also to have more accurate logging by handling exceptions by their type. 

• Project on GitHub

External References

• System exceptions;