VB.NET Try/Catch/When - Stay away or does it have its use?

Question

VB.NET has, unlike c#, a feature to conditionally catch exceptions in a Try/Catch/Finally block.

I thought I read somewhere that this is usually bad practice as it encourages people to put (business) logic in the exception handling mecanism and that you essentially end up with a glorified GoTo.

Try
     // Do something
Catch ex As MyException When [condition]
     // 
End Try

So are there legit cases to use the When feature or should we stay away from it?

This has probably already been answered but I was unable to find anything relevant due "When" being a pretty bad keyword for a search.

Answer 1

The usual case I can think of is when you only want to capture a specific exception, based on the content of that exception. E.g.:

Try
     // Do something
Catch ex As SqlException When ex.Number = 547
     // Constraint Violation
End Try

Which saves you from capturing all SqlExceptions, then examining the Number property, and then having to re-throw the exception if it doesn't match.

See also The good and bad of exception filters:

For instance, if you have a fairly general exception, like COMException, you typically only want to catch that when it represents a certain HRESULT. For instance, you want to let it go unhanded when it represents E_FAIL, but you want to catch it when it represents E_ACCESSDEINED because you have an alternative for that case. Here, this is a perfectly reasonable conditional catch clause:

Catch ex As System.Runtime.InteropServices.COMException When ex.ErrorCode() = &H80070005 

The alternative is to place the condition within the catch block, and rethrow the exception if it doesn’t meet your criteria. For instance:

Catch ex As System.Runtime.InteropServices.COMException 
    If (ex.ErrorCode != &H80070005) Then Throw 

Logically, this “catch/rethrow” pattern does the same thing as the filter did, but there is a subtle and important difference. If the exception goes unhandled, then the program state is quite different between the two. In the catch/rethrow case, the unhandled exception will appear to come from the Throw statement within the catch block. There will be no call stack beyond that, and any finally blocks up to the catch clause will have been executed. Both make debugging more difficult. In the filter case, the exception goes unhandled from the point of the original throw, and no program state has been changed by finally clauses.