Why Use Error Handling

If you leave out error handling, Access will treat all errors equally, by displaying a nonfriendly error message and abruptly ending the procedure. Even worse, if you are using the runtime mode of Access, the entire application will close. This is not what you want users to experience.

Figure 9-1 shows an example of an error message that Access will display if you attempt to divide a number by zero in your application. Sure, technically it indicates what happened, but what is the user supposed to do about it? And what if they click the Debug button? They'll be looking at your code!

Microsoft Visual Basic

Run-time error '11':

Division by zero

End I

Debug

1 Help

Figure 9-1

Also, when Access encounters an error, it abruptly ends the procedure. It does not run another line of code; it just terminates the function or sub that contains the error. So, it can often leave things hanging—open objects, open forms, the hourglass pointer, warnings turned off.

Amateur or Pro? When your code is being evaluated by another programmer, one of the easiest things for them to check is whether you have proper error handling. No matter how good your code is, without error handling you may look like a beginner. It's worth making sure that every procedure has error handling.

Now for the good news: Error handling isn't difficult. By using some easy techniques and code templates, you can make sure that your application never suffers an unhandled error. If you establish a standard way to handle errors, you can make it easy to implement in every procedure you write. It may not be fun or glamorous, but it will certainly make your application better.

0 0

Post a comment