Is anyone here using a global error handler for Word?
Is anyone here using a global error handler for Word?
Hi,Originally Posted by xCav8r
Well don't know what you mean by a global error handler?
I always use a the same error handling function over and over again in all my procedures.
You can have it pop-up a msgbox or have it print an error log. I'm not on my own computer now so can't access my own errorhandler function.
But found something like it:
http://www.vb123.com/toolshed/04_acc...orhandling.htm
Is this what you're looking for?
_________
Groetjes,
Joost Verdaasdonk
M.O.S. Master
Mark your thread solved, when it has been, by hitting the Thread Tools dropdown at the top of the thread.
(I don't answer questions asked through E-mail or PM's)
in general, a global error handler is a very bad way to code.Originally Posted by xCav8r
it is far better to have localized handlers that know the specifics of the errors for each procedure.
a global handler is less flexible and tends to produce fesghetti code.
one of the real attractions if the .net languages is try ... catch.
Hi Howard,
Yes indeed this is very true.
If you know what could happen then you should provide for that in your error handling.
The way I use a global handler as stated was for a error log. (that is if I understood the question) And mostly those errors that you didn't expect and have the log state in which part of the stack the error occured.
This very handy cause people can send it over to you and could help with debugging from a distance.
But of course things you can expect should be handled in a normal Select Case statement for the error nr on Case Else I like to go to the error log.
Later..
_________
Groetjes,
Joost Verdaasdonk
M.O.S. Master
Mark your thread solved, when it has been, by hitting the Thread Tools dropdown at the top of the thread.
(I don't answer questions asked through E-mail or PM's)
"Global" was a poor choice of words. I'm doing everything now at the local level, but I was curious if anyone had developed a nifty routine that accepted all unhandled errors from individual routines for logging and/or messaging along with other relevant info. I remember seeing something on the web that did this and also looked at the stack to get the offending procedure.
I'd love to use VS Tools for Office, but my current contract is to write all this stuff in VBA.
Well I should have something like that so I'll be sure to look it up for you.
_________
Groetjes,
Joost Verdaasdonk
M.O.S. Master
Mark your thread solved, when it has been, by hitting the Thread Tools dropdown at the top of the thread.
(I don't answer questions asked through E-mail or PM's)
Well I'm not here tomorrow so I decided to just find a good one for you on the MSDN.
This does exactly what you want:Click here
Enjoy!
_________
Groetjes,
Joost Verdaasdonk
M.O.S. Master
Mark your thread solved, when it has been, by hitting the Thread Tools dropdown at the top of the thread.
(I don't answer questions asked through E-mail or PM's)
Yes, this is great. The only thing it's lacking is grabbing the proc name from the stack. Thanks, Moose.
Well your Most welcome...Originally Posted by xCav8r
The Moose? O well a Moose lives in the Forest and a MOS MASTER in a FORUM!
Could you explain why the function should pick the procedure from the stack?
Whit that code you don't need that..your calling this code from each procedure and in the call you give a optional parameter with the name of the sub?
You have to call it anyway why not give the name while your add it?
_________
Groetjes,
Joost Verdaasdonk
M.O.S. Master
Mark your thread solved, when it has been, by hitting the Thread Tools dropdown at the top of the thread.
(I don't answer questions asked through E-mail or PM's)
There's two separate issues:Originally Posted by xCav8r
1. Where to do the actual error checking. At the local level is best.
2. How to create error logs. That's most easily done by having each separate error handler pass its info to a single separate procedure called by all the error handlers.
For use with VBA, VB 6 is easier to use than VB .NET.
For Office programming, I see no reason to use the .NET lanhuages, as long as VBA is still the prime macro language for Office, unless there is some functionalty that is not attainable via VB 6. Not to mention, tho I will because it is very important, VB 6 code can be compiled and protected from prying eyes, not so with VB .NET and C#.
Moss , only wanting to avoid having to copy and paste the name and enquote it. Also, that page I had read (unless my memory is getting imaginative) suggested that you could capture the order of procedures called. That would be helpful to me, since I have oodles of routines in these global templates I'm making. If I'm going to recreate the error, I have to find out which routine started the whole process.
1. I agree. In fact, I don't know how you could effectively do it at a global level. I have religiously adhered to the model I learned from the autocode of those nasty Access wizards back in the day:Originally Posted by Howard Kaikow
[VBA]
Function ProcedureName(ArgumentList) As DataType
' Procedure comments.
' Declare local variables and constants.
On Error GoTo ProcedureName_Err
' Procedure code.
.
.
.
ProcedureName = True (or some other return value)
ProcedureName_End:
' Cleanup code that closes open files and sets object variables = Nothing.
Exit Function
ProcedureName_Err:
ProcedureName = False
Select Case Err.Number
Case AnticipatedError#1
' Handle error #1.
Case AnticipatedError#2
' Handle error #2.
Case UnAnticipatedErrors
' Handle unanticipated error.
Case Else
' Handle unforseen circumstances.
End Select
Resume ProcedureName_End
End Function
[/VBA]
Right! This is what I would like to discuss. I'm very curious what other people are doing for this.Originally Posted by Howard Kaikow
You mentioned this before, and I agree that VB 6 has the aforementioned advantages over VB .NET, but some of us are restricted to what we have. As for VBA over .NET for Office programming...http://blogs.officezealot.com/chris/...3/26/1092.aspxOriginally Posted by Howard Kaikow
Hi,Originally Posted by xCav8r
Yes I understand what you mean but this code has to be used within each sub/function, etc...And then it will work properly.
I don't know if it's possible to get the procedure from the stack that's causing the error by code(handler)
I know there's a tool within the VBE to call the stack but if you could do something like that with code??? (Have never looked for it..so if there's time I'm on it)
Enough for one day...tada..
_________
Groetjes,
Joost Verdaasdonk
M.O.S. Master
Mark your thread solved, when it has been, by hitting the Thread Tools dropdown at the top of the thread.
(I don't answer questions asked through E-mail or PM's)
This looks promissing as well: Click
Later..
_________
Groetjes,
Joost Verdaasdonk
M.O.S. Master
Mark your thread solved, when it has been, by hitting the Thread Tools dropdown at the top of the thread.
(I don't answer questions asked through E-mail or PM's)
Yeah! That last link treats the same material I was talking about. You da mouse, mos.
Nah..you silly..You are!Originally Posted by xCav8r
You're welcome and enjoy your debugging. (Wil have a play with that last article myself..like that one)
_________
Groetjes,
Joost Verdaasdonk
M.O.S. Master
Mark your thread solved, when it has been, by hitting the Thread Tools dropdown at the top of the thread.
(I don't answer questions asked through E-mail or PM's)
I'm working on the last article myself. Prolly gonna combine that with the first then develop some options for logging and messaging. Initially I'll log to a file, but I'll enhance it as I have time with the ability to log to Access, SQL Server 2000, MySQL, and SQLite.
It looks as if there is no way to avoid cutting and pasting the the procedure name following what the article says. Looks like the call stack is only available for viewing. Bummer. Since there's cutting and pasting required, however, that bring up another issue where I'd like some input/discussion. I use a template (so to speak) for my procedures...
[VBA] Sub RoutineName()
'Comments: what it does and how to use it
'Local Variables and Constants
On Error GoTo RoutineName_Error:
RoutineName_Exit:
Exit Sub
RoutineName_Error:
'Local Error Handling
'Unexpected Error Handling
MsgBox Err.Number & ": " & Err.Description
Resume RoutineName_Exit
End Sub
[/VBA]
I usually cut and paste this into new routines, changing RoutineName obviously. I do this for every procedure without exception, but I do it out of habit. It certainly would be easier to use generic label names like those suggested in the second article...
[VBA]
Sub AdvancedErrorStructure()
'Comments: What the current procedure does and how you use it
'Local Variables and Constants
If gcfHandleErrors Then On Error GoTo PROC_ERR
PushCallStack "AdvancedErrorStructure"
PROC_EXIT:
PopCallStack
Exit Sub
PROC_ERR:
' Local Error Handling
' Unexpected Error Handling
GlobalErrHandler
Resume PROC_EXIT
End Sub
[/VBA]
I'm considering adopting these generic labels. What do the rest of you use?
One could allow all errors to filter up to an error handler in another procedure, but that's bad coding.Originally Posted by xCav8r
There's only 1 way.Right! This is what I would like to discuss. I'm very curious what other people are doing for this.
Create a log file when the program starts and have ALL error handlers write info to that file, perhaps info to that od a previis session.
VSTO Is much ado about nothing.You mentioned this before, and I agree that VB 6 has the aforementioned advantages over VB .NET, but some of us are restricted to what we have. As for VBA over .NET for Office programming...http://blogs.officezealot.com/chris/...3/26/1092.aspx
When Office is fully .NET-ozed so macros can actually be written in the .NET languages, that would be a time to consider using the .NET languages instead of VB 6.
We're on the same page here. A truly global error handler in VBA seems like it would be unwieldy. If it were to be effective, I don't think it would be cost-beneficial.Originally Posted by Howard Kaikow
Judging from your comments, you're obviously more experienced than the average VBA programmer. I would be interested in learning more from you on this subject. Do you normally write all errors to a log--even handled ones? If you are logging handled errors, how have you benefited from that? Got any tips, comments, or code to share? Do you log to a text file, database, or something else? What sort of information do you store?Originally Posted by Howard Kaikow
I'd have to go check the bookmark in the most recent book I've been reading (a C# book) to find out what page I'm on.Originally Posted by xCav8r
Although the mechanisms available may be different, error handling in VBA is really no different than in any other programming language.
The tip is to write the code in such a way to minimize error handling.Judging from your comments, you're obviously more experienced than the average VBA programmer. I would be interested in learning more from you on this subject. Do you normally write all errors to a log--even handled ones? If you are logging handled errors, how have you benefited from that? Got any tips, comments, or code to share? Do you log to a text file, database, or something else? What sort of information do you store?
I very rarely find the need to check for specific errors.
Proper program design greatly reduces the chance of unexpected errors.
Usually, when I test for an error, I do not care what is the error.
For example, I've recently been investing the behavior of PowerPoint and I needed to find out whether PowerPoint was already runningg, so I included On Error Resume Next right before the GetObject statemant and juat test whether ANY error occurred. If an error occurred, don't care what it is, then I create a New instance of PowerPint, if there was no error, then PowerPoint was already running and I merrily roll along using the running instance.