The Error Class Revisited

Apr21
by on April 21, 2014 at 11:30 am
Posted In: Around the Web, Classes, Events

In the comments to Error Handling Via an Error Class, Peter found that the problem with this method is the absence of the Stop and Resume in the error handler than let you debug at the line that caused the error. Yeah, that stinks. Then Jase got me thinking that I just wouldn’t create the class in debug mode. Well, that wasn’t quite right. What needed to happen was that the error handler should not be set in debug mode. Here’s a rewrite of the entry point procedure.

Sub EntryPoint()
   
    Dim clsError As CError
   
    gbDebugMode = False
                   
    If Not gbDebugMode Then On Error GoTo ErrHandler
   
    Set clsError = New CError: clsError.SetLoc "Module1", "EntryPoint"
   
    SubProc1
     
ErrExit:
    Exit Sub
   
ErrHandler:
    Set clsError = Nothing
    MsgBox Err.Description
    Resume ErrExit
   
End Sub

When gbDebugMode is False, the error handler is set and it works as described in the original post. That is, the user gets a message box and the code exits gracefully. When gbDebugMode is True, the error handler is not set. It’s like you don’t have an error handler at all – because you don’t. When in debug mode, you get kicked to the line that caused the error.

Is that that last hurdle?

└ Tags: