What Microsoft Help says
"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!"