The Error Class Revisited

By in Classes, Events on .

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?

12 thoughts on “The Error Class Revisited

  1. Alex Godofsky

    It seems like Microsoft could save everyone a whole lot of effort by updating VBA to C# or VB.NET.

  2. David

    Note, you can achieve a similar result with Tools | Options in the Visual Basic editor. Just set the option to break on all errors. I frequently do this to defeat my error trapping when I want to look for a bug.

  3. Lars

    Hi together,

    has anybody tried this under Windows 8 and Office 2013?! I really like this ErrorClass and it worked fine for all my vba-code.
    My problem is that the same file (absolutely no modifications) handles the errors under windows 7 (at home) and does not handle errors und windows 8 (at my company). When the code jumps back from the main-procedure into the error-class, the err-object is always NOTHING. So there is no error-handling anymore with this tool :(

    Has anybody experience with this… or any ideas?!
    Thanks for any help.

    Greets,
    Lars

  4. Dick Kusleika Post author

    That’s strange Lars. There shouldn’t be any difference between Windows or Office versions. Check your VBE Properties, specifically Tools – Options – General – Error Trapping and make sure they’re the same in both versions.

  5. Lars

    Hello Dick,

    thanks for your quick answer. The only thing I did not try was to restart the computer. This morning everything was fine with the error class again.

    Thanks a los and have a very nice weekend.

    Greets,
    Lars

  6. Lee

    Hi Dick

    It looks like the issue i have of the error not being passed back up the stack is due to it being generated in a user form. Checking the call stack it shows a line for ‘[]’ immediately before the raised error. There doesn’t seem to be any way around this according to this article – http://www.excelforum.com/excel-programming-vba-macros/509430-form-err-raise-error-not-trapped-by-entry-procedure-error-handler.html.

    Looks like i’ll have to set up custom events for known errors. Not sure what the best course would be to handle unknown errors… Any ideas?

    Thanks

  7. Lee

    The call stack shows this entry: ‘Non-Basic Code’ surrounded by angle brackets and square brackets. It got swallowed in my previous post.

  8. Dick Kusleika Post author

    That stinks Lee, but you’re exactly right. You would have to treat every event sub in your userform like an entry point procedure. But that’s probably not so bad. I think I do that with the PED method.

    So even if a sub calls Userform1 and is error handled, your Userform_Intialize event has to have its own error handler. Any subs you call within the userform that aren’t event procedures (because you probably don’t call them) would work I think. But every event procedure would need an On Error.

  9. Joe Williamson

    Hi Dick,

    Shouldn’t the msgbox come before setting the error object to nothing?

    Awesome idea! Love the stack trace it produces!

    Thanks

  10. Joe Williamson

    Actually if you put the message box before setting the class to nothing it messes up the time in your log since the program waits for you to close the dialog box before it writes the final log entry. I changed the function to store error data in variables before destroying the object and then show it after destroying the object. You probably even stated somewhere and I may have just missed it.

    Cheers!

Leave a Reply

Your email address will not be published. Required fields are marked *

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax