If you're interviewed for a Visual Basic job, there's a good chance you'll be asked about error handling. One of the questions is likely to explore your general strategy for dealing with errors, and the answer the interviewer is usually looking is "I put On Error Goto statements in every function, subroutine and event handler". But why?

A thoughtful strategy for handling errors is essential, of course, but this widespread emphasis on error-handling code in every function is puzzling. There are two reasons to put error handlers in a function: (1) to handle errors, and (2) to help pinpoint the source of unexpected errors. I think reason (2) is over-rated; among Visual Basic programmers it is over-rated to the point of neurosis.

Fundamentally, and obviously, error handlers are for handling errors. A good design will anticipate errors and provide handlers for them, usually based on some kind of transaction model to recover to known states. Other errors are discovered during construction and unit testing, and the transaction model is updated to cope with these errors too. But after all this is done, there remains the spectre of unexpected errors.

It's this 'unexpected errors' card which is dramatically overplayed in Visual Basic coding. Frankly, one reason why such emphasis is placed on unexpected errors is that in a typical Visual Basic development, little design gets done and unreliable code is 'prototyped' all the way to product delivery. Testing is frequently unplanned and often grossly inadequate. A lot of fancy names are are misused to cover up these sins - RAD, iterative development, evolutionary protoyping and so on - but in the end it's just bad practice.

With the best will in the world, it's not possible to plan for every unexpected VB runtime error, so to make our programs robust we need to plug the cracks by firewalling every event handler (or, more correctly, everything that can be invoked from [<Non-Basic Code>]). However, it's fatalistic and unconvincing to suggest our code is of such miserable quality that the chances of failure are distributed evenly throughout. The simple fact is, if we design our programs carefully before writing any code, unexpected runtime errors are few and far between - they are, literally, the exception. Proper placement of top-level error handlers ensures that such exceptions will never go unreported, but the amount of time, programming effort and bloated code often devoted to reporting the precise location far exceeds the usefulness of such information.

This preoccupation with tracking the exact location of unexpected errors seems peculiar to Visual Basic. Are there any other common languages in which such obsession is an accepted technique? Certainly in C++ and Java it is not the norm. The comp.lang.c++ FAQ notes that the Throw/Catch model makes code cheaper to write by focusing exception handling in the relatively few routines that can actually correct the problem, and in the Annotated C++ reference Manual, Bjarne Stroustrup says this: "Exception handlers are assumed to be rare compared to function definitions...The aim is to allow programs to be constructed out of fault-tolerant subsystems without requiring attention to exception handling in every function. In other words it is not reasonable to make every function fault-tolerant."

Of course these two C++ references simply re-affirm the intended purpose of exception handling (handling exceptions), not the pinpointing of unexpected errors, and perhaps we need to consider why few programming books even talk about unexpected errors. Surely we'll conclude that it's because such errors are, by definition, assumed to be rare.

Undoubtedly, the precise tracking of errors is essential at the development stage where we may be experimenting with new controls and ActiveX components, but by the time we deliver the product it has served its purpose. And since VB already has such a development-mode tracking system built in ( Break on All Errors), is there really any need to write our own?