Error Handling Made Simple

[randem]

One of the biggest problems programmers have is debugging their programs. Here are an examples of an error routine that will aid you in finding where in your code the actual problem arises when you have unexpected errors. There is also a routine that will show you how to handle expected errors.

Unexpected Errors

Public Function YourFunction(...)
 
Dim ...
 
    On Error GoTo YourFunctionErrRtn
        ...
 
    Exit Function
 
YourFunctionErrRtn:
 
    Stop
    Resume Next
End YourFunction

This type of error function will allow you to enter the IDE debug mode (only if you are running in the IDE) on an error and then you can step through (f8) to the next line in your function directly after the line that caused the error. Now you know exactly where the error occurred. You can use tools such as ******* or MZTools to add this type of code to every function in your program or you may only want to add it to some function of your app if you know the problem areas.


Expected Errors

When you have expected errors you can handle the error in this fashion:

Public Function YourFunction (...)
 
Dim ...
 
    On Error Resume Next    ' Disable error handling
 
    Err.Clear
    a = a/0         ' This can be any instruction that may cause an error
 
    If Err.Number <> 0 then ' This must come directly after the instuction you have that may cause an error
        ' Handle Error
    End If
 
    On Error GoTo 0
 
End YourFunction

[Doomguy0505]

Err.Clear is a shorter way instead of setting Err.Number to 0

[brucevde]

Here are an examples of an error routine that will aid you in finding where in your code the actual problem arises when you have unexpected errors.

Why not just set the "Break on All Errors" option.

[randem]

Why not just set the "Break on All Errors" option.

Because some errors you might want to handle in the code as per my second example and some errors you just want to ignore (experienced programmers only). Break on all errors will annoy one if your code handles errors inside the code.

[randem]

Err.Clear is a shorter way instead of setting Err.Number to 0

That's a good point. I changed it.

[si_the_geek]

Using "Stop" is a bad idea in my opinion, as it may not get removed before the code is compiled (especially if there is lots of code that would need to be checked).

I would use "Debug.Assert False" instead, as it does the same job in the IDE, but has no effect when compiled.

[randem]

Actually Stop is a good idea. I did not include the conditional statement for debugging.

IE.

If DebugFlag then
     Stop
     Resume Next
End If

I forgot where I was posting...

[si_the_geek]

Well that still takes more code than my suggestion, and requires the addition of a flag variable (which somebody may leave set to True in their compiled program), but it is a valid method.