What’s new in C# 6.0? - Exception Filters


C# 6.0 brought another great new feature named “Exception Filters” along with Visual Studio 2015 and .NET 4.6. If you didn’t try yet the preview version of the new IDE, go and grab it to get your hands dirty with the new features before it actually releases.

 

Today in this post, we will discuss about the new feature “Exception Filters”. Read more to learn about it. Don’t forget to share the feature links in your network.

 

 

Don’t forget to read my previous posts on this series:

Exception filters” is a CLR capability which is already present in Visual Basic and F#, but was not present in C#. In C# 6.0, Microsoft included this feature for CSharp developers to use in their code. If you want to use Exception Filter, you have to declare it in the same line where you declared the catch block, just like this: catch (Exception ex) if (FilterIsTrue). Here, if the parenthesized expression after the “if” returns true, the associated catch block will execute. Otherwise, it will move forward.

 

Expression Filters can be used in many ways. They are preferable to catch and re-throw because they keep the stack intact. If the exception later causes the stack to dump, you can see the original source of it, rather than just the last place where it was re-thrown. Isn’t it good?

 

Check out below to know, how you can write the Expression Filters in catch statement of any try {} catch {} block. This is just a sample to help you understand it better, but you can use it in different way.

 

Whats new in CSharp 6.0 - Exception Filters

 

Here you can actually see how it executes when the said line calls and how the debugger actually passes to the next if statement of the catch in case the if statement evaluates false. Not only you can check for conditions, but also can call some methods to log the details of the entire stack trace.

 

Whats new in CSharp 6.0 - Exception Filters

 

So, what’s your opinion about this feature? How will you use it in your project? Don’t forget to share your comments below. And yes, if you have any feedback on my post, do not forget to let me know.

 

I am available on Twitter, Facebook, Google+. Do connect with me to  subscribe to my feed to get the updates on what I share over those social networks. Subscribe to my blog’s RSS feed and Email Newsletter to receive the new article publish notification in your inbox.


 


If you have come this far, it means that you liked what you are reading. Why not reach little more and connect with me directly on Twitter, Facebook, Google+ and LinkedIn. I would love to hear your thoughts and opinions on my articles directly. Also, don't forget to share your views and/or feedback in the comment section below.

16 comments

  1. If you just use "throw" (not "throw ex") the stack trace will remain intact even "old-school"

    ReplyDelete
    Replies
    1. the point is to be able to branch and have different error handling logic handle the error depending on conditions.

      if you catch / throw, sure, the stack trace is intact, but not only have you not created a branch, you haven't even handle the error, but instead punted the handling of the error to someone else.

      Delete
  2. I think I'd rather us a switch statement

    ReplyDelete
  3. What's the difference between this and catching the specific exception? For example Catch (NullReferenceException ex). Is there some sort of added benefit?

    ReplyDelete
    Replies
    1. being able to catch NullReferenceException is equivalent to
      if exception is a null reference exception
      and if that was all you ever wanted, then there would be no need for this new feature

      but what if you want to use a Boolean expression that is not directly related to the exception.
      such as:
      if i'm on the main dispatcher thread
      if this is the 3 time I've tried this logic
      if my exceptionHandlingService is instantiated

      Delete
  4. Akiel is right on: why not just catch specific exceptions?

    ReplyDelete
  5. This comment has been removed by the author.

    ReplyDelete
  6. Sorry but this just seems redundant and silly. using a catch block for each specific exception is much more efficient / readable as Akiel pointed out. There must be a better explanation for this feature.

    ReplyDelete
  7. The feature is not about specific exceptions but their properties - say when a user enters an email, and you wish to trap whether it violates a specific unique index, you can trap that SQLException (say by filtering on the message containing that index name) but leave others to bubble through to normal error handling. It's a relatively minor improvement in elegance, but it is one nonetheless.

    ReplyDelete
  8. Not impressed of this feature. As it has been previously mentioned, a switch-case or specific exceptions can be used instead. Anyway, most if all, I think that the example used is not good.

    ReplyDelete
  9. @David, yes, the stack trace remains intact if you rethrow in a catch block, but then the following catch blocks won't be considered. No, the major benefit of this feature is that the filters are evaluated BEFORE the stack is unwound. The consequence is that if the exception isn't eventually caught, the dump (or the debugger) will show the original location where it was thrown, rather than the last place where it was rethrown, which means you can inspect the state of the variables on the stack. If you catch and rethrow, the stack is unwound, and you lose access to the state of the stack where the exception was thrown.

    Anyway, the example in the article is not a very good one to illustrate this benefit, because the exception will always be caught eventually, so as mentioned above, a single catch block with a switch would be enough.

    ReplyDelete
  10. Yet more code candy to make awful code.....

    ReplyDelete
  11. This comment has been removed by a blog administrator.

    ReplyDelete
  12. I read something interesting here: http://www.volatileread.com/Wiki/Index?id=1087

    "There is a misconception that if we use the "throw" statement in the catch block instead of "throw ex", your stack is preserved. This results because people only think about the Exception's StackTrace property and not CLR stack."

    ReplyDelete
  13. This comment has been removed by a blog administrator.

    ReplyDelete

 
© 2008-2016 Kunal-Chowdhury.com - Microsoft Technology Blog for developers and consumers | Designed by Kunal Chowdhury
Back to top