You learn something new everyday…

Ok, I know that Paul knew this, but did anyone else notice that the VB.NET Try...Catch syntax includes a 'when' clause?

       [ tryStatements ]
    [ Catch [ exception [ As type ] ] [ When expression ] 
       [ catchStatements ] ]
    [ Exit Try ]
    [ Finally
       [ finallyStatements ] ]
    End Try


    Optional. A Catch statement with a When clause will only catch exceptions when expression evaluates to True. A When clause is only applied after checking the type of the exception, and expression may refer to the identifier representing the exception.

I never did! I can't think of a good use for it right at this moment, but I'm still shocked that I never noticed it before... now what to do with it?

Comments (10)

  1. This is one of those cases where a feature of the CLR is exposed to VB.NET and not to C#.

    It’s not something I’ve ever used, but I’ve seen a few examples that make sense.

  2. Jeff Julian says:

    As you may have seen, professionally, I am a VB.NET developer now (still write C# after hours) so thanks for the tip. I will find someway to use it one of these days.

  3. Phil Scott says:

    I was thinking along the lines of SQLExceptions. I wonder if you could catch something along the lines of

    catch ex as SQLException when ex.Number = 18456 ‘Invalid username / password

  4. Wallym says:

    Knew it but took a while to get my mind around what it was good for.

  5. Alan Fryer says:

    Never new that. I find myself just looking up syntax as I need it (former C++, Java and C# guy that picked up VB.NET).

    To me it would be great if you were constructing lots of objects in a try block and you were not sure which failed. This assumes that you could do things like:


    Catch ex as exception where var is Nothing

    Catch ex as exception where var2 is Nothing

    End Try

    I’ll try it sometime.

  6. Seen it and seen it used. Functionally, it’s equivalent to AndAlso so, I guess that you’d use it to do conditional stuff based on the state of variables when the exception occurred:


    Catch ex As OutOfRangeException When i < 0

    Catch ex As SqlException When cnn Is Nothing


    My main problem with doing something like:

    Catch ex As SqlException When ex.Number = xxx

    Catch ex As SqlException When ex.Number = xxx

    Catch ex As SqlException When ex.Number = xxx

    Catch ex As SqlException When ex.Number = xxx

    Catch ex As SqlException When ex.Number = xxx

    Is that it will lead to longer blocks of code and puts more distance between your Try and your End Try. This leads to code that is harder to read and maintain. For this type of error handling I’d be much more inclinded to do something like:

    Catch ex As SqlException

    HandleSqlError( ex )

  7. I forgot to mention, if you take a look at the example I gave:

    Catch ex As OutOfRangeException When i < 0

    You can see that the When condition clearly enables you to limit the scope of your catching down to exceptions that you are expecting could occur in the normal course of your program flow.

    Now, that’s the theory; would I ever use it – NAH! Probably not, I think I’ll just stick to:


    ‘ insert 800 lines of code


    ‘ do nothing

    End Try


  8. Frans Bouma says:

    Is it of any use? I mean: there is an exception, OR you handle it at that level OR you don’t, but that doesn’t depend on a state of a variable, but the exception itself. Inside the catch clause, if you decide to bubble the exception, youcan always rethrow it. Simply a weird construct that’s IMHO not that useful.

  9. Mark Hurd says:

    I knew it existed because it’s mentioned when discussing security. The Where clause code is executed when the runtime is trying to determine how far up the stack to unwind, but the stack is still in place, so there’s lots of (stack-based) security scenarios to consider…

    IMHO there’s nothing wrong with "weird" rarely used constructs — as long as they’re not going to be removed from the language!

Skip to main content