Consulting

Page 1 of 3 1 2 3 LastLast
Results 1 to 20 of 53

Thread: Global Error Handler

  1. #1
    VBAX Expert xCav8r's Avatar
    Joined
    May 2005
    Location
    Minneapolis, MN, USA
    Posts
    912
    Location

    Question Global Error Handler

    Is anyone here using a global error handler for Word?

  2. #2
    Administrator
    VP-Knowledge Base
    VBAX Guru MOS MASTER's Avatar
    Joined
    Apr 2005
    Location
    Breda, The Netherlands
    Posts
    3,281
    Location
    Quote Originally Posted by xCav8r
    Is anyone here using a global error handler for Word?
    Hi,

    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)

  3. #3
    VBAX Mentor
    Joined
    Sep 2004
    Location
    Nashua, NH, USA
    Posts
    489
    Location
    Quote Originally Posted by xCav8r
    Is anyone here using a global error handler for Word?
    in general, a global error handler is a very bad way to code.
    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.

  4. #4
    Administrator
    VP-Knowledge Base
    VBAX Guru MOS MASTER's Avatar
    Joined
    Apr 2005
    Location
    Breda, The Netherlands
    Posts
    3,281
    Location
    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)

  5. #5
    VBAX Expert xCav8r's Avatar
    Joined
    May 2005
    Location
    Minneapolis, MN, USA
    Posts
    912
    Location
    "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.

  6. #6
    Administrator
    VP-Knowledge Base
    VBAX Guru MOS MASTER's Avatar
    Joined
    Apr 2005
    Location
    Breda, The Netherlands
    Posts
    3,281
    Location
    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)

  7. #7
    Administrator
    VP-Knowledge Base
    VBAX Guru MOS MASTER's Avatar
    Joined
    Apr 2005
    Location
    Breda, The Netherlands
    Posts
    3,281
    Location
    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)

  8. #8
    VBAX Expert xCav8r's Avatar
    Joined
    May 2005
    Location
    Minneapolis, MN, USA
    Posts
    912
    Location
    Yes, this is great. The only thing it's lacking is grabbing the proc name from the stack. Thanks, Moose.

  9. #9
    Administrator
    VP-Knowledge Base
    VBAX Guru MOS MASTER's Avatar
    Joined
    Apr 2005
    Location
    Breda, The Netherlands
    Posts
    3,281
    Location
    Quote Originally Posted by xCav8r
    Yes, this is great. The only thing it's lacking is grabbing the proc name from the stack. Thanks, Moose.
    Well your Most welcome...

    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)

  10. #10
    VBAX Mentor
    Joined
    Sep 2004
    Location
    Nashua, NH, USA
    Posts
    489
    Location
    Quote Originally Posted by xCav8r
    "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.
    There's two separate issues:

    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#.

  11. #11
    VBAX Expert xCav8r's Avatar
    Joined
    May 2005
    Location
    Minneapolis, MN, USA
    Posts
    912
    Location
    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.

  12. #12
    VBAX Expert xCav8r's Avatar
    Joined
    May 2005
    Location
    Minneapolis, MN, USA
    Posts
    912
    Location
    Quote Originally Posted by Howard Kaikow
    1. Where to do the actual error checking. At the local level is best.
    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:

    [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]

    Quote Originally Posted by Howard Kaikow
    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.
    Right! This is what I would like to discuss. I'm very curious what other people are doing for this.

    Quote Originally Posted by Howard Kaikow
    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#.
    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


  13. #13
    Administrator
    VP-Knowledge Base
    VBAX Guru MOS MASTER's Avatar
    Joined
    Apr 2005
    Location
    Breda, The Netherlands
    Posts
    3,281
    Location
    Quote Originally Posted by xCav8r
    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.
    Hi,

    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)

  14. #14
    Administrator
    VP-Knowledge Base
    VBAX Guru MOS MASTER's Avatar
    Joined
    Apr 2005
    Location
    Breda, The Netherlands
    Posts
    3,281
    Location
    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)

  15. #15
    VBAX Expert xCav8r's Avatar
    Joined
    May 2005
    Location
    Minneapolis, MN, USA
    Posts
    912
    Location
    Yeah! That last link treats the same material I was talking about. You da mouse, mos.

  16. #16
    Administrator
    VP-Knowledge Base
    VBAX Guru MOS MASTER's Avatar
    Joined
    Apr 2005
    Location
    Breda, The Netherlands
    Posts
    3,281
    Location
    Quote Originally Posted by xCav8r
    Yeah! You da mouse, mos.
    Nah..you silly..You are!

    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)

  17. #17
    VBAX Expert xCav8r's Avatar
    Joined
    May 2005
    Location
    Minneapolis, MN, USA
    Posts
    912
    Location
    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?

  18. #18
    VBAX Mentor
    Joined
    Sep 2004
    Location
    Nashua, NH, USA
    Posts
    489
    Location
    Quote Originally Posted by xCav8r
    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:
    One could allow all errors to filter up to an error handler in another procedure, but that's bad coding.

    Right! This is what I would like to discuss. I'm very curious what other people are doing for this.
    There's only 1 way.
    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.

    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
    VSTO Is much ado about nothing.

    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.

  19. #19
    VBAX Expert xCav8r's Avatar
    Joined
    May 2005
    Location
    Minneapolis, MN, USA
    Posts
    912
    Location
    Quote Originally Posted by Howard Kaikow
    One could allow all errors to filter up to an error handler in another procedure, but that's bad coding.
    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.

    Quote Originally Posted by Howard Kaikow
    There's only 1 way.
    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.
    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?

  20. #20
    VBAX Mentor
    Joined
    Sep 2004
    Location
    Nashua, NH, USA
    Posts
    489
    Location
    Quote Originally Posted by xCav8r
    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.
    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.

    Although the mechanisms available may be different, error handling in VBA is really no different than in any other programming language.

    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?
    The tip is to write the code in such a way to minimize error handling.
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •