11–20 of 20 posts
as I see it they aren't much more than "more syntactic sugar"
If the behavior can be expressed using previously existing syntax, then a construction is syntactic sugar. This is not true in this case. (sorry if you knew this already)
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.
Earlier quoted context omitted.
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…
What happens when the exception test expression throws an exception?
---
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%... [1] http://stackoverflow.com/questions/28879320/what-happens-if-...
What happens when the exception test expression throws an exception?
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/ms18…
Returning false in this situation feels a bit hacky IMO.
Earlier quoted context omitted.
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/ms18…
Good find, thanks! Returning false in this situation feels a bit hacky IMO.
[0] http://blogs.msdn.com/b/dotnet/archive/2009/08/25/the-good-a...
Earlier quoted context omitted.
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/ms18…
Good find, thanks! Returning false in this situation feels a bit hacky IMO.
I think its the only way to go. The filter function that throws could be attached to any catch block all the way up the call stack. Where exactly would you start the search for a exception handler in that case?
> 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…
I was blown away by the lambda syntax. I get the need for it from a parsing perspective, but my god.