How do we deal with Error Handling in a library?

This came up because of the NiceDlookup function I’ve published previously. In that function, the Err object is used to “Raise” errors. The reasoning behind this for this particular function was to make the function fully compatible with the DLookup function and the errors it raises. Here is the latest version from this web site that includes allowing spaces in table/query names without brackets:

https://www.accessjumpstart.com/access-object-names-with-spaces-and-nicedlookup/

So that function uses Err.Raise as noted in order to produce the same custom error messages as DLookup does, thereby making it a drop in replacement. It also is enhanced to to allow more flexible usage using multiple tables and other possible field functions and combinations not possible with the function included with Access. It also cleans up the DB object after it’s done.

But for this message I am focusing on error handling.

In the Access JumpStart application framework, we provide a global error handler which you can use manually when you use error handling in the application code, or it can be used in conjunction with vbWatchdog which will catch all unhandled errors and pass them to a specified function. In the case of a user with vbWatchdog installed we have different options available within the app framework options on what to do with them. Options include logging errors to the system log, presenting all errors using a standard dialog, or if using vbWatchdog, displaying all errors using the vbWatchdog dialog box. In addition you can choose these different options for how to handle the errors whether the error is handled or unhandled in the application.

Ultimately, our strategy for error handling does not rely completely on the library. If there are errors happening in an application, the library can’t truly know all the possible actions that should be taken. If you want to trap for errors in your application, you should always do so and handle the errors for the particular situation that the application is currently in.

For example, you might want to just shutdown the application and not allow it to even start if you can’t access the backend.

Or, if the application has specific ODBC timeout errors, perhaps you want your application to retry those errors. Trying to come up with every possible desired handling of an error was deemed to be impractical in terms of library functions. Functions should work as anticipated, but if they can’t for some reason, they should throw an error to the application function that called it. That’s the approach we take in Access JumpStart.