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.
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.