The Err Object

To realize a bit better what you can possibly do with your own version of error handling, as opposed of relying solely on Visual Basic's internal functionality, we'd better have a look at the different parts of the error object it self.

Events
Err.Clear
Err.Raise

Required properties
Err.Number

Optional properties
Err.Description
Err.HelpContext
Err.HelpFile
Err.LastDllError
Err.Source

About the event properties

Err.Clear is called solely to clear the most recent error from the error structure. In the event you fail to clear the error, it would persist and be called again, especially in longer functions where you may resume the function at an earlier point than simply to exit the functions or sub running. Failing to clear the event would also cause the error to persist cross modules if occurring in a function of the public or global scope.

Err.Raise is called to force an error of the specified, optional properties to occur. Thereby you can call up the reference to an error at run time to generate a list of all errors, display a specific help context ID or help file for specific errors to the user.

It is also an event that we will use in the definition of our own errors later on in this article.

The required properties

There is only one required property in the error object model. Namely, the Err.Number. In order to find all data and information pertaining to a specific error events properties, this number is the "ID" number for the event it self, allowing you to call back the more detailed information about the error. Provided of course that such information exists and has been programmatically included in the compiled files or classes called by your application.

The optional properties

Err.Description is a string expression describing the error raised. If the description is omitted, the Visual Basic runtime module will attempt to localize a correlating description based on the Err.Number. Once again remember that if you define your own error number and it clashes with an existing one, this may be cause for some concern if your user is not provided a description correlating with your error number. If the Visual Basic runtime module is unable to locate such a description, it will simply generate a standard output saying "Application-defined or object-defined error". Rather empty, and meaningless to your end user.

Err.HelpContext is an identifier to a help context ID in a provided help file for your application. Once more, if omitted, the VB runtime will attempt to establish a link to the existing Visual Basic Help file based on the error number value, if it exists. The best thing to do is to define this value to 0 not to confuse your users, when no help file has been provided for your application.

Err.HelpFile is the fully qualified path to an MS Windows *.hlp file used by your application. If omitted the application will attempt to use the fully qualified drive, path, and file name of the Visual Basic Help file, if existing on the end users machine.

Err.Source is a string expression displaying the name of the object or application that generated the error raised. If you should set this programmatic ID your self, use the form project.class. If you do not specify the source, it is automatically generated for you in form of the name of the current project. This is displayed at design time in the menu under the menu option; Project >> Project Properties >> General >> Project Name.
 
Err.LastDllError is only returned or generated by call to a dynamic-link library (DLL). This property is read-only and will only return the error code number. Study the Visual Basic help file further for details on how to obtain DLL error codes, and study the DLL providers documentation closer to find the relevant meaning to each error code and how to handle the error codes passed form DLL files.