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.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
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?
It seems like Microsoft could save everyone a whole lot of effort by updating VBA to C# or VB.NET.
I like the idea! Will implement in my next project and get back to you with any feedback! :-)
SIMPLE! SIMPLE! and Elegant. I love this and think you nailed it this time.
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.
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
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.
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
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
The call stack shows this entry: ‘Non-Basic Code’ surrounded by angle brackets and square brackets. It got swallowed in my previous post.
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.
Hi Dick,
Shouldn’t the msgbox come before setting the error object to nothing?
Awesome idea! Love the stack trace it produces!
Thanks
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!