An error is a condition which, if unhandled, would cause the application to crash or malfunction.
An error occurs when your application does not work. Thus, any discussion of error handling means that you are covering up your mistakes. The user does not make errors.
Realistically, events will happen that are beyond your control, but you cannot take that attitude as a programmer. A prevention strategy should be worked out for each error that is noticed, anticipated, or even known to be possible.
Error handling should prevent the application from malfunctioning when unexpected events occur.
To be useful, an error handling needs to trap and disarm errors that would interrupt the smooth flow of program execution. The more painlessly and transparently the program recovers from the error, the higher the quality of the error handling.
All functions and subs should trap and handle any possible errors. Property routines should trap and correct errors when appropriate, and raise all other errors back to the calling routine.
Certainly error handling is not needed everywhere, but it is minimal excess baggage for those rare occasions when it is not. If you follow the rules above, a sub or function would not need error handling if it called only other subs or functions and made no reference to a property. Here's a common problem.
Private Sub Column_Name_Textbox_GotFocus()
AutoSelect_Control_Text Column_Name_Textbox
End Sub
This looks perfectly safe. The only command is a call to a sub which obeys the rule and traps all errors. Option Explicit is turned on (of course), so the compiler is going to make sure the sub name is correct and that the parameter is a valid control name. What could go wrong? Plenty!
Note the VB compiler does not check the types of complex objects until runtime. Column_Name_Textbox might be some mis-named user class, or the type of object required by the routine might not be a control. Either will cause a runtime error in this routine. Without error handling (as shown), the application will crash in the runtime environment.
Are these errors likely? No. Are they possible? Yes. Well-chosen names for subroutines, objects, and variables minimize the likelihood of such errors, and a solid testing program will catch most of those few that slip through.
This is the only situation where you should EVER have routines without error handling, and you should only consider this when the application is thoroughly tested. The best justification for this deviation is that the error handling makes the containing module larger than VB's 64K limit.
Standard error handling (also referred to as default, debug, or catchall error handling) should be installed in every subroutine and function at the time the function is created. For custom applications and all applications through alpha test, error handlers should report each error to the user.
Record each error in a data file so that the cause of each error can be identified and removed.
Standard Error Example
A simple message box subroutine and an even simpler template make the insertion of this form of error handling a matter of a few keystrokes. Any delay in taking this step is almost certain to result in a net waste of time and effort.
At a minimum, this is error handling that will prevent any error from terminating your application. The minimal effort required to create this structure is paid back in full the first time an error occurs in this routine, and it is an investment that pays dividends from that time forward. Finally, it provides a basic structure for the construction of custom error handling.
Insert custom error handlers to deal with errors that are known to occur and errors that can be reasonably predicted to occur. Use catchall error handlers for all other errors.
Take care not to use error handlers as elaborate GoTo's. Code in error handlers should be limited to the minimum required to correct the error. Code in error handlers should never start another complex execution stream.