Advanced Error Handler

Thought I'd bring peoples attention to an "advanced" error handler that I wrote months back.
Since this is always a topic on conversation I thought it was worth while posting an example.
If you have any questions then give me a shout...post replys in this thread.

Here's the link:

http://www.vbforums.com/showthread.p...hreadid=271178

Woka

PS: Err Handler, ErrHandler, Error Handler, Handling Errors, How To Handle Errors, Dealing With Errors, Displaying Errors, Woof, Glagnorg, Klupnikaf

Quote:

---

Err Handler, ErrHandler, Error Handler, Handling Errors, How To Handle Errors, Dealing With Errors, Displaying Errors, Woof

---

You forgot Glagnorg and Klupnikaf! What if people search for thoose? ha? ha?

Shame on you, SHAME!

LOL

Updated ;)

Someone has mentioned about logging the errors to a log file, so in a few moments I will add the code in to do that.

Woka

I haven't looked at yours yet, but the one I posted in this thread:

http://www.vbforums.com/showthread.p...ighlight=error

Does logging to a log file.

Code has now been updated. It does save all info to a log file...

Does your code allow for "history", ie every sub/function that the code execution has passed through?

Woka

No, but I feel this is kinda pointless, IMO. All I need to know is where the error was generated from (ie. what function) and what the error was generated. Mine does that and is easily implemented with the click of a button (via MZTools) to whatever new function/procedure I add to the project.

I disagree. Having a history of where the code execution has been is a GREAT help.
I single function can be called from MANY different sub/functions. Sometimes the errors are a nightmare to trace, and every little bit of info helps. For me, personally, I have found the history of the code execution to be an absolute god send :D

Woka

To each his own ;)

Completely agreed :D

The reason I say that it's helpful is that in a HUGE application, that may go through say 20 subs in one go, the cause of the error could happen in the 10th sub, but doesn't cause an error until it reaches the 20th one. So really there is nothing wrong with the 20th sub. Having a history allows me to track backwards and find the exact source of the error...

Quick silly example:

VB Code:

Private Sub Woof()
Dim nodItem   As Node   
   Growl nodItem
   Set nodItem = Nothing
End Sub
 
Private Sub Growl(ByRef pnodItem As Node)
   pnodItem.Text = "Fish"
End Sub

The above code is passing a treeview node around.
The error occurs in the sub Growl, however, there is nothing wrong with this sub.
The error actually originates from Woof, as I missed out the line:

VB Code:

Set nodItem = Treeview1.Nodes.Add

If Growl is called from loads of different subs, then I wouldn't know where to start looking. With my code I would know that on this occasion, that caused the error, it was called from Woof, so this would be my 1st port of call to see what was going on.
If you didn't have the history then you wouldn't know where to start looking.

Woka

I see your point. And I will be checking out your handler, but I still stand by my first stance. Then again, I can't say that I've ever passed through more than 5 or 6 subs on the way to an error.

Yes, my opinion but I do agree with Wokawidget, outputing the sub/function as apart of your logging has really helped me in the past to debug HUGE projects.

I have a new super-duper error handler in the pipe line. Does pretty much the same thing, but is much more solid and slightly better coding.
Will post an update tmrw hopefully.

Woka

PS Have a look at the project and let me know of any pros/cons

Is the super duper version what is currently in the Codebank?

Anyway, I was wondering what peoples opinions are on adding line numbers (using MZTools) and then using Erl in this dll to log the line at which the error occurred.

Obviously when you are debugging it is easy to jump to the error line, however, if you have a very large sub and you get

Quote:

---

ERROR NUMBER:
6

DESCRIPTION:
Overflow

---

there is still a fair amount of debugging to work out what is wrong.

How about this?