Exception handling is something that you as a developer need to be aware of, and you must also be very good at discerning what information to display to the end user and what information to log. Believe it or not, writing good error messages is harder than it looks. Too much information displayed to the user might instill a sense of distrust in the software. Too little information logged for debugging purposes is also not useful at all to the poor soul that needs to fix the error. This is why you need to have an exception handling strategy.
A nice rule of thumb is to display a message to the user stating that something went wrong, but that a notification has been sent to support personnel. Think of Google, Dropbox, Twitter (remember the blue whale?), and other big companies. Humorous error pages with a little robot whose arm fell off, or a popular meme displayed to the user is far better than a threatening error page with a full stack trace and red text. It is something that momentarily takes the user's mind off a frustrating situation. Most importantly of all, it lets you save face.

So let's start off by looking at exception filters. These have been around for some time. Visual Basic.NET (VB.NET) and F# devs have had this functionality for a while. It was introduced in C# 6.0 and does more than meets the eye. At first glance, it looks as if exception filters merely specify a condition when an exception needs to be caught. This is, after all, what the name exception filter implies. Upon closer inspection, however, we see that exception filters act as more than just syntactical sugar.