Error Handling

There are various debugging tools to help to locate the source of errors that are detected.
There are various types of errors that can occur when running and writing procedures.
They can be separated into three kinds. The most common of course is the logical error.
The term inline error handling refers to checking for errors after each line of code is executed.
An error handling routine is not a sub or function but is just a section of code marked by a line label.

Sub DoSomeThing(var1 as Variant) 
   On Error GoTo ErrHandler

   Exit Sub
ErrHandler:

   Resume Next
End Sub

To prevent error handling code from running when no error has occurred, place an Exit Sub or Exit Function statement immediatley before the error handling routine.


Handlying Errors

The best way to handle errors is to have a centralized error handling procedure or procedures.
Error dialog boxes offer a few options: end the procedure, get help or enter break mode to debug the code.
Execution will always stop at the offending line of code and it will be highlighted in yellow.
If the project is password protected then to enter debug mode is not an option.


A run-time error will normally cause execution to stop and a message box will be displayed displaying the error number and a short decription the error.
A good application does not let the user see these error messages and rather incorporates error handling to trap errors and take the appropriate action.
At the very least your error handling should display a more meaningful error message.


When you get an error a dialog box will be displayed. Click on the Debug button to find out which line of code is causing the error. If the VBE project is password protected then this button will be disabled.
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.


Your error handler procedures will not work on users PC's if they have the "Break on all Errors" option set in their (Tools > Options)(General tab) of the VBE.


Error Handling Keywords

You can use the "On Error" statement to specify what happens when an error occurs:

PropertyDescription
On Error Resume NextReturns control to the statement following the one at which the error occurred
On Error Resume LabelReturns control to a specified line label
On Error Resume [0]Returns control to the statement at which the error occurred (statement is re-run)
On Error Goto LineLabelExecution jumps to the line label when an error occurs
On Error Goto 0Resets the Err object and resets the Err.Number to zero.
End Sub / Function / PropertyEnds the procedure, function or proeprty
Exit Sub / Function / PropertyExits the procedure, function or property
StopEquivalent of a break point, this will cause the program to enter break mode
EndTerminates execution
Clear??????


What happens here ??

On Error Resume Next 
Set rngRange = Range("DoesNotExist")
lerrorno = Err.Number
On Error GoTo 0
Call MsgBox(lerrorno)


Best Practices

Prefix all error messages with name/abbreviation of the application
To make sure your error messages can be easily distinguished from all other messages


Shortcut Keys

(Alt + F5) - Resume execution (through an error handler).
(Alt + F8) - Steps through an error handler.


Functions

CVErr - Returns the corresponding to a given error number (Variant).

Lorem ipsum dolor sit amet, consectetur adipisicing elit. Illo itaque ipsum sit harum.

Error - Returns the error message corresponding to a given error number (String).

Lorem ipsum dolor sit amet, consectetur adipisicing elit. Illo itaque ipsum sit harum.

IsError - Returns the value indicating if an expression is an error (Boolean).

Lorem ipsum dolor sit amet, consectetur adipisicing elit. Illo itaque ipsum sit harum.


Important

If you do not use an On Error statement then any run time errors are fatal and execution will be stopped and a message box displayed.
Always add an Error Handler to every procedure and function.
Avoid using On Error Resume Next
All objects must be set to Nothing before exiting
Error handling should be displayed if the gbDEBUG_ERRORMESSAGES constant is used and is set to True.
Make sure any screenupdating, cursor or statusbar is always reset including in any error handling.
If an run time occurs inside the actual error handler then control is passed to the calling procedure until an active error handler is found. If none can be found then this is a fatal error.
An error handler is automatically disabled when a procedure is exited.
You can always split the Code window horizontally just drag the split bar
You can use the Immediate window to display the message associated with a particular error. Just type "? Error" followed by the error number


© 2017 Better Solutions Limited. All Rights Reserved. © 2017 Better Solutions Limited

Next