Without error-handling code, Access treats all errors equally, displaying unfriendly error messages and abruptly ending procedures. Even worse, if you are using the runtime mode of Access, the entire application closes. This is not what you want users to experience.
Figure 9-1 shows an example of an error message that Access displays 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 he clicks the Debug button? If he's running an MDB/ACCDB instead of an MDE/ACCDE, he'll be looking at your code!
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 mouse pointer in hourglass mode, warnings turned off, and so on.
Amateur or pro? When your code is being evaluated by another programmer, one of the easiest things for him 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 ...