Introduction
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.