When an error occurs in a procedure that doesn't have an enabled error handler, or within an error handler that's currently running, Visual Basic searches the calls list for another enabled error handler.
For example, suppose the following sequence of calls occurs:
1. Procedure A calls Procedure B.
2. Procedure B calls Procedure C.
3. Procedure C calls Procedure D.
If an error occurs in Procedure D and this procedure doesn't have an enabled error handler, Visual Basic searches backward through the calls list — first Procedure C, then Procedure B, and then Procedure A — and executes the first enabled error handler it finds. If it doesn't encounter an enabled error handler anywhere in the calls list, it displays the appropriate run-time error message and halts your procedure.
Tip
The effect of the search backward through the calls list is hard to predict, because if a Resume or Resume Next statement is encountered in the error handler, execution continues in the procedure where the error handler is found, which isn't necessarily the procedure where the error occurred. To avoid this situation, write a fail-safe error handler that all your error handlers can call as a last resort for errors they cannot handle themselves. This fail-safe procedure can both save the user's data and close your application in an orderly way.