7.2 Old-school unstructured exception handling in VB 6.0 and its disadvantages
You are well aware that the exception-handling model in VB 6.0 required you to jump through hoops in order to handle errors and gracefully exit from a procedure or function.
The exception-handling model that VB 6.0 supported was unstructured and required you to make jumps to a label or a line number that contained the error-handling code to
handle the error. Further more, you had to take precautions to exit the procedure in a normal execution flow when no error occurs by not allowing it to fall through to the
error-handling block. If you had clean up code that was supposed to execute both when an error occurred as well as during a normal execution flow, then you had to make yet
another jump to a label or line number that contains the block of cleanup code. The whole approach was unstructured and often got very messy. To see what we mean, and why this
method of exception handling can be best termed as unstructured, recollect fond nostalgic memories at how you typically handled exceptions in VB 6.0 using the code snippet
shown below, and be prepared to bid goodbye to this pattern of exception handling:
Private Sub BookTicketsForMovie On Error GoTo BookTickets_ErrHandler
Perform business logic to book tickets. Possibility that exceptions could be raised here, say when all
tickets are sold out. BookTickets_Exit:
Ignore any errors here since this is just a resource clean up block On Error Resume Next
Resource clean up occurs here Maybe close up the DB Connection to the movie ticket database and so on
Exit the procedure Exit Sub
BookTickets_ErrHandler: Handle the error based on the error type.
Need to pick up the value of Err.Number and then decide accordingly how to handle the error.
MsgBox Error encountered is: Err.Number MsgBox Error message is: Err.Description
Go through the usual cleanup procedure before exiting the procedure Resume BookTickets_Exit
End Sub
As seen above, you typically use an
On Error GoTo …
statement to redirect any errors to error-handling code marked by a label or line number, such as the
BookTickets_ErrHandler
handler in our example. The VB 6.0 runtime populates the
Err
object that contains all the details about the error that occurred, whose properties can be examined for the error type
that occurred and then a decision can be taken as to how to handle that error. This is a really cumbersome task if your program is capable of generating a lot of error types,
since we need through the rigmarole of determining the exact type of error that occurred using decision statements such as
Select…Case
or
If…Then…Else
before actually handling it. If you had cleanup code that needs to be executed before exit from the procedure, such
as the one under the
BookTickets_Exit
label in our example, then you had to make an
additional jump to the cleanup code or call a common cleanup procedure. As a result, the code becomes very unstructured and difficult to maintain, thus allowing occasional bugs
to creep in silently. VB.NET supports this form of unstructured exception handling too. But it’s generally not recommended that you use unstructured exception handling in
VB.NET because of performance constraints and code maintenance nightmares. It is recommended that use VB.NET’s structured approach to handling errors, which is
the topic of our next section. So be prepared to say a tearful goodbye to unstructured exception handling and say a big hello to the über powerful world of structured exception
handling.
7.3 Structured Exception Handling in CVB.NET