PETER J. MORRIS
Peet is the Technical Director and a cofounder of The Mandelbrot Set (International) Limited (TMS). Peet 12312q1619m , a former Microsoft employee, is acknowledged industry-wide as a Microsoft Windows and Visual Basic expert and is a frequent speaker at events such as VBITS and TechEd. As a developer and lecturer, he has taught Windows (SDK) API, Advanced Windows API, Visual Basic (all levels), OS/2 Presentation Manager, C, C++, Advanced C and C++, Pascal, compiler theory, OWL, Smalltalk, and CommonView.
Since the first edition of this book was released, this chapter has been tidied up a little. I've added some new rules and sidebars about handling errors in components and controls, as well as some examples of handling errors on a server.
What is an error? The short answer is, "Something that's expensive to fix." Dealing with errors is costly in terms of both money and time. As you probably know already, your test cycle will be longer, more complex, and less effective if you don't build appropriate error handling into your code right from the start. You should do all you can to reduce and handle errors in order to reduce costs, deliver quality code, and keep to schedules.
One way to eradicate errors-a way that I'll dismiss immediately-is to write error-free code. I don't think it's possible to write such pristine code. A more realistic way to deal with errors effectively is to plan for them properly so that when they do occur:
The application doesn't crash.
The error's root cause (and thus cure) is relatively easy to determine.
The error is as acceptable and as invisible to the user as is humanly possible.
So what must we do to put a good error handling scheme in place? It's a deceptively simple question with a big (subjective) set of answers. I think that acquiring and then using some fundamental knowledge is where we should start:
Ensure that all your developers truly understand how Visual Basic raises and then dispatches and handles errors.
Make sure that those same developers understand the consequences of writing code that is hard to debug and the true costs of any unhandled error.
Develop a suitable error handling strategy that's based on your understanding of the preceding two points and that takes into account your budget and line of business.
Apply your strategy; demand self-discipline and team discipline.
Handling errors properly in Visual Basic is also a good idea because of the alternative: Visual Basic's default error handling rules are rather severe. Unhandled errors are reported, and then an End statement is executed. Keep in mind that an End statement stops your application dead-no form QueryUnload or Unload events, no class Terminate events, not much of anything in fact.
To help you develop an effective strategy for dealing with errors, I'll go over some ideas that I consider vital to the process. These are presented (in no particular order) as a series of tips. "Pick 'n mix" those you think will suit you, your company, and of course your development project. Each tip is empirical, and we have employed them in the code we write at The Mandelbrot Set (International) Limited (TMS). I hope they serve you as well as they have served us!
|
