

C# 6 exception filters and how they are much more than syntactic sugar - pqpuiq
http://www.volatileread.com/Wiki?id=1087

======
Tenhundfeld
> VB.NET already had this feature

Years ago, I did .NET consulting and switched between C# and VB.NET depending
on the client. Exception filters were the _only_ feature from VB.NET that I
missed when working in C#. I didn't use them often, but in some cases, they
were the cleanest solution.

I've since switched to Ruby and other OSS stacks, but I'm still happy to see
C# get this. It's one less argument for anyone to use VB.NET, which has far
inferior syntax, in my opinion – especially when working with lambdas or
events.

~~~
mreiland
I worked on a VB.Net project once and went to use LINQ...

I was blown away by the lambda syntax. I get the need for it from a parsing
perspective, but my god.

------
dgomez1092
I see the purpose of this as more preventative. I can create a contstraint for
(Exception == "x1") { throw Exception when (x1 == "<filepath>")} Now I can
understand why'd you'd be alerted of this however this would cause parallel
processing latency when it comes to the concurrnt evaluation of when
expecptions can occur instead of code exceution itself. So instead why not run
the code and create log block that for (Exceptions == true) { while (i = 0, i
< y.length, i++) then y= x.length x= write.push(<sys.path>), result =
println(x.trace) }

I believe this will be more effiencient than an excess of concurrent filters.

------
TeMPOraL
What happens when the exception test expression throws an exception?

~~~
pests
edit: Apparently [0] is for VB.net and C++ but I would think including VB.net
would mean the CLR. If so, then C# should be the same. A further SO post on
the topic with no official sources confirms the same at [1]

\---

Found more details at [0]

Apparently the CLR runtime catches them and then causes your exception filter
to return false, as if you had done so yourself.

[0] [https://msdn.microsoft.com/en-
US/library/ms182337%28v=vs.80%...](https://msdn.microsoft.com/en-
US/library/ms182337%28v=vs.80%29.aspx) [1]
[http://stackoverflow.com/questions/28879320/what-happens-
if-...](http://stackoverflow.com/questions/28879320/what-happens-if-the-
filter-of-an-exception-filter-throws-an-exception)

~~~
TeMPOraL
Good find, thanks!

Returning false in this situation feels a bit hacky IMO.

~~~
pests
I found another interesting gotcha in regards to the filter step of exception
handling described at [0]. Its in VB but describes the CLR two-pass exception
handling and how filter functions and finally blocks interact with regards to
state.

[0] [http://blogs.msdn.com/b/dotnet/archive/2009/08/25/the-
good-a...](http://blogs.msdn.com/b/dotnet/archive/2009/08/25/the-good-and-the-
bad-of-exception-filters.aspx)

------
Relys
Here's another article on C# exception filters along with a small keygenme
demonstrating it's use: [http://lifeinhex.com/catch-me-when-you-
can/](http://lifeinhex.com/catch-me-when-you-can/)

------
matthewrhoden1
It looks really weird to me, having that empty catch block. I expect a lot of
issues to accidentally be introduced from poor merges or something.

~~~
Someone1234
I don't understand. Why would you have an empty catch block? He does in his
example but that's an example. I cannot see why you'd even write a catch block
if it was empty in production code (unless you're trying to do some error-and-
continue pattern, which is rare/mostly an anti-pattern).

~~~
mhomde
Or just supress it, for some methods you might want to return a null
value/"null object"/bool rather than have an exception cascade up the chain
and risk crashing the application. I think Exceptions are a bit problematic as
a concept but then again so are null values :)

An easy example are checking if a file exists under Windows 8, it's partly a
product of the currently deficient API's but the fastest way to check if a
file exists is to try to get it and catch the exception, and you'd want to
return bool from a FileExists method

~~~
TeMPOraL
After many years I still don't really grok the idea behind exceptions, and I
get this feeling that I'm not alone with that. There probably is an extremely
smart idea supporting this whole "handle all errors with exceptions" style,
but I haven't seen any good explanation yet; instead what I see most often is
a case of Stockholm syndrome - "it's in the language, it's The $LANGUAGE
Style, it _must be Good_!".

------
landmark2
as I see it they aren't much more than "more syntactic sugar"

~~~
danbruc
Exception filters are not syntactic sugar because they will not unwind the
stack until a true condition is encountered and you really catch the
exception, something impossible to do with the traditional catch-
check-[re]throw mechanism.

