The Classic Visual Basic Err Object Is Gone in Visual Basic .NET

Classic Visual Basic had the Err object and used syntax such as On Error goto myErrorHandler. No matter how we tried to get away from goto statements, because they were part and parcel of error handling in classic Visual Basic, we couldn't escape them entirely. Using the On Error statement along with goto statements is known as unstructured error handling. In unstructured error handling, exception handling is turned on for all code that executes within a procedure by executing an On Error statement within that procedure. When an exception is raised in the procedure after the On Error statement has been executed, the program branches to the label specified in the On Error statement.

The way unstructured error handling worked in classic Visual Basic could be confusing for a novice programmer. If a call were made within one procedure to another procedure and an exception occurred within the called procedure, the exception was propagated back to the calling procedure if the called procedure didn't handle the exception itself. Let's say you have Procedure A and Procedure B in your program. If Procedure A has an error handler, calls Procedure B, and an error occurs, execution immediately branches back from Procedure B to the error handler in Procedure A. When programmers understood how this mechanism worked, everything was fine. However, this approach caused developers to pop open many bottles of aspirin when trying to debug a program. Unstructured error handling using On Error statements can actually degrade application performance and result in code that is difficult to debug and maintain.

Thankfully, this primitive and Visual Basic–specific method of unstructured error handling is gone in Visual Basic .NET. It's been replaced by the structured Try…Catch…Finally syntax that has been used for years in pre-.NET languages such as C++ and Java.