C# 6 Preview: Exception filters

We already have the ability to branch our exception-handling code depending on the type of exception, by using multiple catch blocks:

            try
            {
                Console.WriteLine("Enter a number");
                string inputStr = Console.ReadLine();
                int input = Convert.ToInt32(inputStr);
                Console.WriteLine(5 / input);
            }
            catch(FormatException ex)
            {
                Console.WriteLine("Input must be a number");
            }
            catch(DivideByZeroException ex)
            {
                Console.WriteLine("Can't divide by zero");
            }
            catch(Exception ex)
            {
                Console.WriteLine("Doh");
            }

In C# 6, we will be able to filter exceptions by handling them only if a condition is true. For example, we may want special treatment for exceptions that have an InnerException:

        static void Main(string[] args)
        {
            try
            {
                throw new InvalidOperationException("Invalid operation",
                    new Exception("Justin Bieber is breathing"));
            }
            catch(Exception ex) if (ex.InnerException != null)
            {
                Console.WriteLine(ex.Message);
                Console.WriteLine("  -->{0}", ex.InnerException.Message);
            }
            catch(Exception ex)
            {
                Console.WriteLine(ex);
            }

            Console.ReadLine();
        }

An additional benefit of exception filters is described in the C# feature descriptions (PDF):

Exception filters are preferable to catching and rethrowing because they leave the stack unharmed. If the exception later causes the stack to be dumped, you can see where it originally came from, rather than just the last place it was rethrown.

The same PDF also describes a method to take advantage of the conditional expressions used in exception filters in order to perform some action that uses but does not actually handle the exception. The description and code below are taken from that PDF.

It is also a common and accepted form of “abuse” to use exception filters for side effects; e.g. logging. They can inspect an exception “flying by” without intercepting its course. In those cases, the filter will often be a call to a false-returning helper function which executes the side effects:

private static bool Log(Exception e) { /* log it */ ; return false; }
…
try { … } catch (Exception e) if (Log(e)) {}

Leave a Reply

Your email address will not be published. Required fields are marked *