I have some pretty in-depth experience working with the VB6 exception handling mechanism. I still get an occasional email about my article on Try-Catch exception handling in VB6 in the Sept 2001 Visual Basic Programmer’s journal.

So when I finally got a chance to crack open the Enterprise Application Block and check out the Exception Handling App Block, I was hoping for some pretty nice stuff, or at least something to give me a few ideas.

But what’s there seems pretty underwhelming.

The good news is that most of the stack tracing and related informational-type things that you really had to work very hard at with VB6, are part and parcel to VB.NET. The bad news is that the exception handling application block doesn’t seem to contain much at all to actually make handling exceptions any easier than piling mountains of Try-Catch lines into your source.

Hmm, Try…Catch…Finally, or On Error Goto Handler…Handler: …Resume next

Under the covers, I know they’re very different, but seriously, what I see is just syntactic shuffling.

I’ve always believed that virtually all exception handling in an app should be attributable to individual routines. That’s the way my exception handler for VB6 worked, just without all the syntactic niceties of .NET.

For instance, why shouldn’t I be able to attribute a routine as to how exceptions within it ought to be handled?

<HandleExceptionsByContinuing> _

Public Sub MySub(arg1, arg2, arg3)
    x = 1 / 0

End Sub

In this case, I’ve declared that for this particular method, exceptions ought to be handled by simply continuing execution of the code.

Other cases might raise a specific error, reraise the original error, reraise the original error wrapped in an outer exception, etc. Granted, my example may not be great here.

Most routines are supposed to be so small that having more than one TRY statement would be lame anyway, right? And most of the code I’ve looked at containing Try Catch blocks only contain one in a method anyway.

For those routines where you definitely need to handle specific exception in specific ways, you still have the Try statement to fall back on, but even then, I tend to believe that every exception in an app should be routed through a single handler that can be configured to do certain things, be it emailing the exception, logging it, or (and I’m not recommending this, mind you!) ignoring it altogether.

Littering the workings of your code with boilerplate Try Catch filler strikes me as equally onerous as those comments like:

'Increase the count variable by one

Count = Count + 1

Ugh.

But, just like a well placed comment, when the workings of the code are better explained with inline exception handling, TRY away!

Might be time for my own Enterprise Exception Handling Block…