The best error handlers are written when the routine they protect is being written. Tools that insert error handlers for you help but are not the answer. These t 20120e411u ools can be used to retrofit semi-intelligent error handlers into your code once you're through writing-but is this a good idea? Your application will be error handler-enabled, that's for sure; but how dynamic will it be in its handling of any errors? Not very!
We rarely use any kind of tool for this purpose because in fitting a blind error handler there is little chance of adding any code that could recover from a given error situation. In other words, by fitting an error handler after the fact, you might just as well put this line of pseudocode in each routine:
On Error Condition Report ErrorYou're handling errors but in a blind, automated fashion. No recovery is possible here. In a nutshell, a blind error handler is potentially of little real use, although it is of course better than having no error handling at all. Think "exception" as you write the code and use automation tools only to provide a template from which to work.
|