Consulting

Page 3 of 3 FirstFirst 1 2 3
Results 41 to 53 of 53

Thread: Global Error Handler

  1. #41
    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
    Got it working now with Access and SQL Server 2000. Before I do any more, since I'm going to submit this for a KB entry, I thought I'd solicit suggestions for other information to capture. Here's what I'm currently tracking:
    • Error Number
    • Error Description (from scripting engine)
    • Call Stack (ProjectName.ModuleName.ProcedureName)
    • Line Number originating error
    • Date/Time Stamp
    • Windows Account Name
    • Message that the user saw
    • Optional message from the developer to troubleshooter
    Hi,

    Yepz looking good and I can't wait to get my hands on reviewing that kb entry!

    I would include the Computername in my errorlog.
    You could use: [VBA]
    MsgBox Environ("COMPUTERNAME")[/VBA]
    Depending your needs theres much more great data you can get from Environ function!

    Also if you're code is spanning multiple projects I'd advice to use: Err.Source (look it up it can hold the object/project/class causing the error)

    I can't think of anything else for now because you're covering so much more then I normally do. I think this entry will be very handy.

    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)

  2. #42
    VBAX Wizard
    Joined
    May 2004
    Posts
    6,713
    Location
    Right on Howard. In essense you are keeping to your local error handling dictum. Locally speaking, if the issue is: PowerPoint running - Yes? No?, then who cares what the error is with a No? It is No, so you make an instance. If it is Yes, you use that one.

    The only real other possibility with error handling a No would be a check to see if there IS a PowerPoint to make an instance of. Not likely the case, but what if PowerPoint was not installed? You would an error (not running), but you would get another error trying to make a new instance.

  3. #43
    VBAX Expert xCav8r's Avatar
    Joined
    May 2005
    Location
    Minneapolis, MN, USA
    Posts
    912
    Location
    At the risk of sounding argumentative but only wanting to get a discussion going where we can learn from one another, I'll say I agree that good programming means anticipating as many possibilities as can be imagined and handling them in the body of your code so that they don't become errors, but I also recognize that you can't always get the sort of information that you want by testing conditions. To avoid duplicating a menu item, for example, I might attempt to delete it (in case it already exists) before trying to add it. Along that line, it seems to me that there will always be a need for handling specific errors--and that sort of thing is best when handled at the procedure level. I haven't disagreed with that concept in this thread.

    Those things said, despite how much I try, it's irresponsible to assume that I've planned for every possibility. When I'm working with complex projects, especially when that's in a team environment, the potential for unanticipiated errors increases dramatically. In such cases, I think a global error handler is essential. First, it provides a means of documenting unhandled errors during the development process that acts as a convenient list of issues to address before unleashing your project on your users. Second, if done appropriately, it facilitates troubleshooting down the road.

    Frankly, I'm surprised that there hasn't been more of an interest from the more experienced programmers on this forum. That might be the result of my own ignorance, but this seems like one of those best practice discussions that could be of benefit to all.

  4. #44
    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 fumei
    Right on Howard. In essense you are keeping to your local error handling dictum. Locally speaking, if the issue is: PowerPoint running - Yes? No?, then who cares what the error is with a No? It is No, so you make an instance. If it is Yes, you use that one.

    The only real other possibility with error handling a No would be a check to see if there IS a PowerPoint to make an instance of. Not likely the case, but what if PowerPoint was not installed? You would an error (not running), but you would get another error trying to make a new instance.
    Hi Gerry,

    Isn't this about this topic: http://www.vbaexpress.com/forum/show...newpost&t=3302
    _________
    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. #45
    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
    Frankly, I'm surprised that there hasn't been more of an interest from the more experienced programmers on this forum. That might be the result of my own ignorance, but this seems like one of those best practice discussions that could be of benefit to all.
    Hi,

    did my last post give you any new ideas?

    I think the majority of programmers write small programs that only need a little amount of error handling.

    If you write a big program the capabilities of a good error handling and error log are of great need! In perticular from debugging from a distance...

    So Please go ahead and make your routine perfect so we can all benifit from 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)

  6. #46
    VBAX Expert xCav8r's Avatar
    Joined
    May 2005
    Location
    Minneapolis, MN, USA
    Posts
    912
    Location
    hehe...thanks...and yes, lots of ideas, but I haven't picked it back up again.

  7. #47
    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
    hehe...thanks...and yes, lots of ideas, but I haven't picked it back up again.
    Ah Ok...welcome...But uhmss please don't wonder of to far or lose focus because I want you to submit that entry!
    _________
    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. #48
    VBAX Expert xCav8r's Avatar
    Joined
    May 2005
    Location
    Minneapolis, MN, USA
    Posts
    912
    Location
    I won't wander too far, but it might be a while before I kick out something with which I'm satisfied. The benefit of the delay to VBAX KB users will be that it'll be incorporated shortly into various projects serving several hundreds of people, so the major kinks should be worked out prior to submission.

    In the meantime, I've added err.source. For some reason I had thought that err.source always returned the name of the application, but I see now that I was mistaken. At any rate, I'm not sure that it adds anything at this point, since I push the call stack with ProjectName.ModuleName.ProcedureName before there is an error, and err.source is obviously only available after an error has arisen. I suppose I could send the err.source as a parameter to the global error handler, but I don't see any advantage to that method over what I'm currently using. Perhaps you have some thoughts on that matter.

    I've also included a loop to enumerate everything in the environment table.

  9. #49
    VBAX Wizard
    Joined
    May 2004
    Posts
    6,713
    Location
    Argumentative? Hardly. This is a serous discussion, and we have to be free to bring forth stuff.

    I agree. But let's see if we can agree on terms. What exactly does a global error handler DO? Handle ALL errors? You could easily end up with a monster routine larger than the original app.

    I think there are some differences in error types.

    User Input CONTENT errors, I think, should be handled locally. If an input field requires numeric, and alpha is input, that should be trapped locally - at the procedure level. I do not see the need to pass those to a global error handling routine.

    User Input LOGIC errors can be handled at a module level, as normally, after all the information is collected locally (with local error trapping), said information is processed. That is, it is passed along - to the document, or to another module. So, at this oint, the content itself is good, but when parsed logically with other elements, there may be errors. So before the current module finishes there should be final error trapping. This is not "global" really, but it is sort of....

    Then finally, I guess there is true global error handling. This handles errors coming out of the modules themselves. It assumes the content of data elements is good (handled locally), the logic within the module is good (handled at module level), but now checks to see if the all the modules TOGETHER (or globally) are good.

    Does this makes any sense? Topic is open for discussion.

    I absolutely agree that team processing opens up the possibility of unanticipated errors.

  10. #50
    Administrator
    VP-Knowledge Base
    VBAX Guru MOS MASTER's Avatar
    Joined
    Apr 2005
    Location
    Breda, The Netherlands
    Posts
    3,281
    Location
    Hi,

    Take all the time you need! It's a good thing you're going to test it first in the field. The code will benefit from that.

    For me personally the only errors I'm trully interested in are the ones I didn't anticipate!

    That means that my select case will handle all of those foreseen and my error logging gets the ones I didn't. More important including the source in the stack and the Error line (Erl())

    That would be sufficient. But like I said before if you want something to help you debugging from a distance the errorhandler couldn't be big enough.

    Don't forget if you design your error handling wel you could also use a separate DLL to process the Error log. This could be slimmed down for a release version but if need be you could easily replace that with a bulkier one!

    But the Error lines have to be in the code to begin with otherwise that trick won't work...

    So yes I'm very interested in the way this global thingie is growing...

    So for now I hope I've given you again some more water to grow!
    _________
    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)

  11. #51
    VBAX Expert xCav8r's Avatar
    Joined
    May 2005
    Location
    Minneapolis, MN, USA
    Posts
    912
    Location
    I found another article with some useful information on the subject of error handling: http://www.developerfusion.com/show/1741/

    Quote Originally Posted by fumei
    What exactly does a global error handler DO? Handle ALL errors? You could easily end up with a monster routine larger than the original app.

    This thread is long, and the worthy content is sporadic and convoluted, so I don't fault you for not having read all of the posts that gradually led to answers to the questions you pose here. 500) {this.width=500;this.alt='Full View';}" border=0>

    I admitted that global error handler was a slight misnomer, because it conveys to some the idea of a single error handler, which is not the concept I intended when I started the thread, and I apologize for not having been clearer up front. For the purposes of this discussion, global error handler refers to a set of routines that in conjunction respond to and log unhandled errors.

    Quote Originally Posted by fumei
    Does this makes any sense? Topic is open for discussion.

    I?m not sure that I totally follow what you?re saying, but I think some of your comments might have been directed to a different notion of global error handler.

    I group my procedures together with procedures that deal with similar things. For example, I have a standard module that does stuff with printers (gets information about available printers, selects trays, changes duplex settings, sends big print jobs in batches to avoid problems with memory limitations in certain printers, etc). Although some procedures work with others in the same module to achieve a goal, the same could be said of procedures across modules. And, because it?s not uncommon for a task to be accomplished using multiple procedures all in different modules, it?s difficult to conceive of something I could do at a module level (standard, not class) along the lines of what you described.

    Quote Originally Posted by MOS MASTER
    Don't forget if you design your error handling wel you could also use a separate DLL to process the Error log. This could be slimmed down for a release version but if need be you could easily replace that with a bulkier one!
    That's a consideration, I think, for farther down the road.

    Quote Originally Posted by MOS MASTER
    But the Error lines have to be in the code to begin with otherwise that trick won't work...
    Indeed. That'll need to be the last step before releasing a project that uses this error handling scheme.

  12. #52
    VBAX Mentor
    Joined
    Sep 2004
    Location
    Nashua, NH, USA
    Posts
    489
    Location
    Quote Originally Posted by xCav8r
    At the risk of sounding argumentative but only wanting to get a discussion going where we can learn from one another, I'll say I agree that good programming means anticipating as many possibilities as can be imagined and handling them in the body of your code so that they don't become errors, but I also recognize that you can't always get the sort of information that you want by testing conditions. To avoid duplicating a menu item, for example, I might attempt to delete it (in case it already exists) before trying to add it. Along that line, it seems to me that there will always be a need for handling specific errors--and that sort of thing is best when handled at the procedure level. I haven't disagreed with that concept in this thread.

    Those things said, despite how much I try, it's irresponsible to assume that I've planned for every possibility. When I'm working with complex projects, especially when that's in a team environment, the potential for unanticipiated errors increases dramatically. In such cases, I think a global error handler is essential. First, it provides a means of documenting unhandled errors during the development process that acts as a convenient list of issues to address before unleashing your project on your users. Second, if done appropriately, it facilitates troubleshooting down the road.

    Frankly, I'm surprised that there hasn't been more of an interest from the more experienced programmers on this forum. That might be the result of my own ignorance, but this seems like one of those best practice discussions that could be of benefit to all.
    Experienced programmers have learned how to write code that minimizes the need for "global error handlers".

    It just takes time to learn how to do this.

    The first step is to write modular code, i.e., isolate functionality into individual subs/functions.

    As you write each sub/function, where needed, put a local error handler in the sub/function. You will be surprised at how rarely you will need such a handler.

    For most tasks, you can get by without a local error handler just by using On Error Resume Next in the obvious places, and, where needed, checking for the error locally, not in an error handler.

    In other cases, On Error Goto Somewhere will be used to skip blocks of code.

    Rarely do I ever find a need to know the particular error number,

  13. #53
    VBAX Expert xCav8r's Avatar
    Joined
    May 2005
    Location
    Minneapolis, MN, USA
    Posts
    912
    Location
    Quote Originally Posted by Howard Kaikow
    Experienced programmers have learned how to write code that minimizes the need for "global error handlers".
    I'm wondering if we're talking past one another in this thread. I explained what I meant by global error handler in my second post, and I reaffirmed that definition in my last post. I'll repeat what I wrote, because I don't think you read it. For the purposes of this discussion--at least when I use it--a global error handler refers to a group of procedures that work in conjunction to log unhandled errors. A global error handler does not mean a single error handler.

    If, for some reason I'm mistaken, and you have understood this phrase in the way that I am using it, then I'd like to understand why you think it's good practice to assume that you've anticipated every possible error. That doesn't sound like something that an experienced programmer would do. In fact, it seems to me that only an inexperienced programmer would do this.

    Futher, the very text I wrote--which you quoted--agrees with the concept of this statement. I've already stated that "good programming means anticipating as many possibilities as can be imagined and handling them in the body of your code so that they don't become errors". Either you're not reading what I have written, or I haven't understood your responses. If the latter is the case, then it would be helpful to have more detail from you to explain where I've gone wrong.

    Quote Originally Posted by Howard Kaikow
    The first step is to write modular code, i.e., isolate functionality into individual subs/functions.
    I already do this. If I don't do it when I write it, I invariably alter it after. When I write any code--regardless of the language--I always try to make it reusable. If anything, I'm guilty of doing that too often, even with projects that'll never be modified or have elements repeated. That's my methodology.

    Quote Originally Posted by Howard Kaikow
    As you write each sub/function, where needed, put a local error handler in the sub/function. You will be surprised at how rarely you will need such a handler.
    This paragraph is what convinced me that you haven't read what I've written in this thread. If I anticipate an error that can be corrected, then I will will handle it at the procedure level. Sometimes I do this the hard way--though sometimes unnecessarily. For example, if I need to access a file, I check to see if the file exists using code, but I could simply test for err.number = 53 (and a few others), but I prefer to check it the file actually exists with a function I have written specificially for this purpose.

    Still, I never assume that I have anticipated every possibility. That's why I want to log all unhandled errors.

    Quote Originally Posted by Howard Kaikow
    For most tasks, you can get by without a local error handler just by using On Error Resume Next in the obvious places, and, where needed, checking for the error locally, not in an error handler.
    If there had been any question in my mind about what you understand by global error handler, I think this text lays the question to rest. Resume next assumes the error is not fatal. When I anticipate such an error, then I'll resume next..but I'm not talking about anticipated errors.

Posting Permissions

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