VB Catch ... When: Why so special?

re: VB Catch ... When: Why so special?

int19h — Fri, 10 Oct 2008 16:50:19 GMT

There's also the convenience part of it. In C# catch-rethrow solution, with default VS settings, it won't break on the original throw down the stack (because it's caught upwards), but it will break on rethrow if the filter fails, because that one is uncaught. On VB, if the filter fails, there is quite literally no catch, and the debugger correctly breaks on the line that originally threw the exception.

re: VB Catch ... When: Why so special?

Ted — Wed, 15 Oct 2008 00:03:09 GMT

Please deprecate this feature in VB. Keep VB and C# consistent. The minimal reduction in the number of lines of code is outweighed by the extra effort you need to understand/maintain the code.

re: VB Catch ... When: Why so special?

int19h — Wed, 15 Oct 2008 14:08:20 GMT

Er... you want to deprecate an immensely useful VB feature just because C# doesn't have it? How about spending 5 minutes (you know, the amount it takes to type "Where" in MSDN Library index and glance at the first paragraph of the article that opens) to learn the language you end up coding in?

If anything, I'd rather ask to have that feature in C#. And I'm really a C# programmer, not a VB one.

re: VB Catch ... When: Why so special?

Daniel Earwicker — Mon, 02 Mar 2009 23:19:56 GMT

The real value of this is that when an exception is being filtered, nested finally blocks are not run first. If they run, they corrupt the program state or cause further problems, before you can examine the original one. That is what happens when you try to filter exceptions with catch/throw. It is vital to have exception filtering for this reason. C# is incomplete without it.

re: VB Catch ... When: Why so special?

TedsAnIdiot — Wed, 05 Aug 2009 18:41:32 GMT

Yeah, deprecate the more evolved functionality... My name says it all.