Distributing Application Updates
Error Handling
Error handling is one of those things that no one really wants to do. We all like to think that we have accommodated for every contingency and that we can test better than any user could possibly screw up. Wrong. You can pretty much guarantee that if we make an application bullet proof, a user will immediately fire arrow at it instead.Now, having done this many times before, it is just simply impossible to accommodate every error that may occur. Different Windows machines will generate different problems and we will always miss at least one fatal circumstance. So how do we trap these?
My solution in the Distribution Engine was not to worry about them at all. Let the user work it out for themselves. Well, to a degree anyway. Take the window displayed in Figure 1 for instance.
To generate this error, I renamed a table in the primary database. Now, as this is an unlikely event, I decided not to cater for it. However, I do actually pop-up a message describing the error and then supply the user with some options.
Pretty much all errors in Visual Basic are grouped in some way. In this case I simply checked for an error between a certain range of numbers and determined that these were fairly serious errors. As a result, certain buttons on the error screen have been enabled or disabled according to the severity of the problem.
Now I can concentrate on the errors that are likely to happen and supply useful descriptions rather than the ones returned by Access and/or Visual Basic.
I also included a Further Information tab, which lists all the routines accessed leading up to this error. This means that when the technical support call happens, we can track down exactly what the user was doing to generate the fault and fix it quickly.
