"Trappable errors can occur while an application is running. Some trappable errors can also occur during development or compile time. You can test and respond to trappable errors using the On Error statement and the Err object. Unused error numbers in the range 1 - 1000 are reserved for future use by Visual Basic." QUOTED MS Visual Basic 5 Help file Vb5.hlp

Additional numbers used are in the range of 35000 - 35749 for ComCtl32.OCX and ComCt232.OCX files. For the picture clip controls the added numbers are ranging in the 32000 block. Further more 35750 - 35999 for the INET control MSInet.ocx may be regarded used/reserved.

An important remark for those using the MS Chart control is the following.

"The MSChart control's errors that occur during program execution are handled like other errors. You must write your own error handling routine to trap and manage errors. " QUOTED MS Visual Basic 5 Help file Vb5.hlp

I will not discuss exception handling here since this is a subject much better suited for its own article. Exception handling is also a much more common way to approach error trapping when working in languages like C and C++ or Java and it is a 1/8 (=bit) beyond the grasp of this brief article.

In addition to the scope of the Err object, users can also define their own error codes, using the CVErr(errornumber) function. This function will allow assignment of any valid number in the range 0 - 65,535 of a Variant whose VarType is vbError.

In this case, and for the purpose of this article I will not go into details in the use of CVErr either.

For reference, I have included the normally reserved error numbers above, thereby allowing you to get an idea in which range you may find useable and free error numbers to assign in your own code.

You should also be aware of the following.

In most modules and controls, there is extensive error trapping built in. At least on the professional level of coding. You should make sure that the OCX/DLL files and other classes you call in your application does not use reserved error numbers for their internal processes before assigning additional ones to your own code. This could not only cause errors in your code, but also have a very odd affect on your trapping the errors.

Say for instance that a used runtime function has reserved the error number 24998. If you at the same time construct a general class file or module to trap your own error numbers, and you used the error number 24998 somewhere else. Imagine the weird look on the face of your end users, when they are loading an image file and are met with the error; "Sorry the application couldn’t download your backup!"