C# 6 exception filters and how they are much more than syntactic sugar
1–10 of 20 posts
Re: C# 6 exception filters and how they are much more than syntactic sugar
#2as I see it they aren't much more than "more syntactic sugar"
Re: C# 6 exception filters and how they are much more than syntactic sugar
#3I see the purpose of this as more preventative. I can create a contstraint for (Exception == "x1") { throw Exception when (x1 == "")} 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 ), result = println(x.trace) }
I believe this will be more effiencient than an excess of concurrent filters.
Re: C# 6 exception filters and how they are much more than syntactic sugar
#4as I see it they aren't much more than "more syntactic sugar"
The point of the article was the fact there is a functional difference in how the runtime/code behaves in this instance.
Syntactic sugar would be something like automatic property getters and setters in C#; they just shorten the syntax drastically and the compiler or runtime unroll your code to the traditional implementation.
In this case you can interrogate things normally bound up into the exception instance itself, like the message without having to hit the catch block to wait for it to be hydrated. Once you enter that catch block things happen in the runtime that are costly so avoiding that if possible is the best route.
Re: C# 6 exception filters and how they are much more than syntactic sugar
#5It 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.
Re: C# 6 exception filters and how they are much more than syntactic sugar
#6as I see it they aren't much more than "more syntactic sugar"
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.
Re: C# 6 exception filters and how they are much more than syntactic sugar
#7as I see it they aren't much more than "more syntactic sugar"
When you throw an exception on the CLR, it will 1) walk the stack looking for candidate catch blocks, and 2) if it finds one, it will long jump to that catch block, destroying all stack frames between the frame that threw the exception and the frame for the function that contains the catch block.
Exception filters are a CLR feature that modify this process a little. Now, when an exception is thrown, it still walks the stack looking for candidate catch blocks, but whenever it identifies a candidate, it will call the exception filter function (a function from exn -> bool, where exn is the exception being caught by the Catch block). If the function returns false, the CLR will disregard this candidate catch block and continue searching. C# 6.0 merely added some syntax that exposed this functionality of the CLR, the language itself isn't doing this.
Re: C# 6 exception filters and how they are much more than syntactic sugar
#8It 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.
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).
Re: C# 6 exception filters and how they are much more than syntactic sugar
#9It 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.
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).
I wish it were rare, I've seen it in a lot of projects I've had the privilege of dropping in on. They will often check for an error and log it, then "throw;".
edit: to further clarify my objective, I was thinking of a way to make the stack traces better, without risking the maintainability of the code now that I'm aware of the difference. I guess in all it would be best to just remove it. In my case, we've found some strange things in unexpected places and I prefer to not change stuff, unless I understand how the underlying portions work.
Re: C# 6 exception filters and how they are much more than syntactic sugar
#10It 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.
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).
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