Handling Errors in VB/VBA/VBS/ASP

This article will discuss some of the more basic and practical ways to solve general error handling in your Visual Basic applications and MS Office VBA modules. It is in many ways applicable to VBA, VBScript and ASP, in much based on the same syntax and practical solutions in your code.

The goal is also to tech you to generate your own error numbers and error descriptions for inclusion in your source code. Thereby providing you with more than one way to solve the problems of trapping user generated for-seeable errors before they throw a fit in the face of your application end users.

There are several ways of including basic error handling into your applications. The most common one especially for beginners is simply to rely on your working files being operational on all systems. However, considering how many different OCX and DLL files there are available on the growing field of VB, once should consider using more error handling in final products than is otherwise the case. There is no one event so annoying to an end user finding a nifty little freeware with an excellent description to it, teasing you to download the files, go through often not to well defined setups only to find it throwing one undocumented error after another in your face.

Many times such errors can be trapped and avoided by the simplest of ways, in particular if you are working with resource files in ASCII format and need to temporarily store data in text files for use by your application at run time. The most annoying thing is to get an error 52 or 53 on start up saying the file can not be found, rendering your application useless if you forgot to auto generate the needed start up files.

I will also include some samples on how to work around this "run-time" glitch makers and allow you a way to solve these things before they even become a problem to the final user. At least, this is one way, how I solve these issues and it seems to work for my applications.

A word of caution is always in place in working with programming of any kind. When diverting errors and closing them out in one place, make sure that you don’t allow the closing to become a permanent part of your software, clearing the error out for good as it could be useful to actually stop your application at some other point in time. Do NOT soft-code error handling too much and make it to general. Hard coding is sometimes an essential part to really determine the one or few places these exceptions are allowed to occur, rather than allowing your program to neglect an error at a later time.

Not only PERL has more than one ways to do things, just don’t tell that to the PERL programmers, they may take ill to it. (Laughing a bit knowing quiet a few that may lose than grin on their faces for thinking they have a simple language to work with.) *In ref. to O'Reilly's Programming PERL, Chapter 1: An overview of PERL, page 2, 2nd edition.