VB & VBA in a Nutshell: The Language

Chapter 6. Error Handling

Who was Murphy? I don't know, but I know his law well enough: "Whatever can go wrong will." As application developers, we quickly learn that assumption and complacency lead to disaster. It's no good telling users that you didn't expect them to enter the word Four instead of the number 4, or that you didn't know that one part of the system entered a Null value into a database field that you were trying to read. Neither users nor MIS managers want excuses; they want applications that work—and by work I mean applications that don't curl up in the corner and die at the first sign of trouble. Sure, errors and situations beyond your control—such as a database server that unexpectedly goes off-line—are going to happen, but that shouldn't kill your application. At the very least, you should be in a position to report back to the user what the problem is without generating a runtime error that will bring down your application.

This chapter hasn't been written as an exhaustive reference of all the statements, objects, methods, and properties involved in VB error handling, but rather as a guide to help you plan your error handling. It lays out the error-handling template for you, and also sets out some of the ground rules involved in resolving the everyday and not so everyday exceptions that can be thrown at your program.

We'll assume that you have set the Option Explicit statement at the start of each module (so there can't be any variable name typos),^[1] and ...