|
One of the most annoying problems when trying to finish a VB system is how to add the error handling code. It has to be done, because otherwise any unexpected errors will simply put up a cryptic error message box and then, when the perplexed user presses OK, the application will just disappear. Adding error handlers to every routine by hand is a real chore, and once the error handlers are in there any further debugging becomes more difficult because it will probably be triggered by any errors rather than the IDE just showing you the line. You can tell the IDE to stop on errors without triggering your handlers, but then it stops on errors you have anticipated, such as an item not being present in a collection, which is even worse. The logger solves all of these problems. You finish the application, including EXEs, EXE servers, DLLs and OCXs, add a reference to the Error Handler DLL, add a couple of lines to your app's startup code, and then, just before the final build of each project, you tell the logger to add error handling, and optionally stack handling, code to the components. It quickly runs through inserting code as required, and you can then build your application confident that unexpected errors will not make your app look like it was knocked up by someone with 2 weeks programming experience, and that if any errors occur you will have a log both of the error message and where it has occurred (if stack tracing was included you even get to see the call stack at the time the error occurred). The next time you come to edit your code you simply tell the logger to remove its code, and it does so, leaving you with just the bits you want to see, not all the extra stuff it had to add. Of course, you shouldn' t be confident about anything the first time you try the logger - not until you have taken a backup of your source and tested it. Babbacombe Computers take no responsibility for damage or loss to your source from the use of the logger. Currently the logger is a VB5 add-in, and the error handling DLL is built with VB5. They will work with VB6 projects, but require the VB5 run-time to be present. An example of the error handling code added. Assume LoadData is a routine which loads some data points from somewhere and places them in a Variant array. There are a number of possible errors which could occur here. Divide by zero is the obvious one which you might remember to allow for, but what if someone else inadvertently changed LoadData so it returned a Variant array of Variant arrays?
Note that no error trap is added to the CalculateAverage function. The logger knows that this cannot be called from outside this application and it therefore doesn't need to add a trap. If an error should occur in the function it will be trapped somewhere above it, in this case in btnCalcAvg_Click. This can be called from the VB runtime, so it does need an error trap. The sort of error message which could be logged by default for this would be E 21 Mar 1999 16:44 Type mismatch (13) The user would see something like
|
|
|