DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 3 of 8 FirstFirst 12345 ... LastLast
Results 31 to 45 of 109

Thread: Correct Error Handling

  1. #31
    Kathleen Dollard-Joeris Guest

    Re: Correct Error Handling

    Richard!

    How long since we last argued??? For old times sake, at least, I gotta
    disagree!

    > for low level error trapping, you need automation to keep it simple!
    > (aside: why don't VB programmers use VB Addins more ?! Or buy one from
    > George ("VB Builder"), fer gosh sakes!)


    Addins are good for things that there is absolutely no alternative to making
    nearly redundant. This example doesn't fly <g>.

    > Private Sub MyRoutine()
    >
    > On Error GoTo GeneralError
    > Call LOG_SessionString("frmDdayReptDialog Sub MyRoutine", "")
    >
    > Debug.Print "doing myroutine"
    >
    > Exit Sub
    >
    > GeneralError:
    > Call LOG_ShowError("frmDdayReptDialog Sub MyRoutine")
    > Err.Raise 65535 ' quietly interrupt caller
    > Exit Sub
    >
    > End Sub


    First, and most sinfully you repeat the name of the sub twice! Bad, bad,
    bad.

    Then you call a function called ShowError in every blasted sub. You either
    have a badly named sub, or you show the error to your user way too many
    times.

    Finally, no where here do you record the VB info on the error: just being
    sloppy?

    ALL you have to do in every sub is stuff the routine name on to a callstack
    and allow VB to raise the error through to a location that can appropriately
    handle the error. Whatever you are doing may NOT be critical to the higher
    level app. You are a lowly peon doing the work you were told to do!!!! You
    do not have the right to complain!!!

    I prefer to stuff the name at the start of the routine, although it can also
    be done in an error handler (5 lines instead of 1).

    VB does a great job of raising errors. Why don't we just cover for its gross
    inadequacy in maintaining a call sequence/stack and let it raise the error
    to the highest point we care about: this would generally be the events, the
    high level (public) routines in middle tier components and _anywhere_ where
    the error would cause clean up work (closing files, etc).
    --
    Kathleen
    (MS-MVP)
    Reply in the newsgroup so everyone can benefit
    --




  2. #32
    Michael Culley Guest

    Re: Correct Error Handling


    Richard

    >>Exactly why do people like the stack to dump?


    Some routines you will know where the stack came from, so it won't be much
    use. But if the routine that the error originated in is a very general routine
    then the call could have come from a hundred places. Hence the call stack
    will be useful.

    One question I have regarding your approach. You call error handling code
    to log each routine called before an error occurs. This means extra code
    being run for every routine, and this extra code includes string manipulation
    (which can be slow). Do you find this slows things down. Do you remove it
    from procs that are called repeatedly or have another method of dealing with
    speed?

    Michael Culley


    "Richard Curzon" <richardcurzon@home.com> wrote:
    >Mike
    >
    > (and Hello to Kathleen, Jim, and all, partly this is response to your
    >posts!)
    >
    >I always read discussions on EH, I don't think it gets the attention it
    >deserves!
    >
    >My EH practice seems a lot like Jim Pragit's, main difference
    > - I prefer call sequence dump to callstack dump
    > - I use a little more standardizing/automation maybe with addins
    >
    >----
    >
    >I've standardized for years now on "EH in every routine", basically. Then

    I
    >adjust to whatever's needed.
    >
    >First about "how" to do it because that's a big factor. It's a lot of lines
    >of code, and If it's tough to do, it won't happen!
    >
    >Then later someting "why" do it.
    >
    >for low level error trapping, you need automation to keep it simple!
    >(aside: why don't VB programmers use VB Addins more ?! Or buy one from
    >George ("VB Builder"), fer gosh sakes!)
    >
    >---- E.g. I write a routine:
    >
    > Private Sub MyRoutine()
    >
    > Debug.Print "doing myroutine"
    >
    > End Sub
    >
    >--- clicking one option in the "error trap" addin makes it look like:
    >
    > Private Sub MyRoutine()
    >
    > On Error GoTo GeneralError
    > Call LOG_SessionString("frmDdayReptDialog Sub MyRoutine", "")
    >
    > Debug.Print "doing myroutine"
    >
    > Exit Sub
    >
    > GeneralError:
    > Call LOG_ShowError("frmDdayReptDialog Sub MyRoutine")
    > Err.Raise 65535 ' quietly interrupt caller
    > Exit Sub
    >
    > End Sub
    >
    >The Error Trap AddIn leaves the cursor on the line "Err.Raise 65535". I
    >delete the line if it's an Event or Sub Main. (probably could have utomated
    >that check, but ... )
    >
    >Usually the line is left in, all the way up the stack. Because usually

    I
    >want the entire chain of calling routines to stop in their tracks.
    >("LOG_ShowError" ignores error 65535 for visuals and logging.)
    >
    >"Why" low level handling: that's where the most useful info is (usually)
    >available. Not always: sometimes several routines in the stack have good
    >info. But you don't want multiple error messages for one error.
    >
    >Example: The low level parse routine knows "the string was badly formatted"
    >...... but only the caller knows "which line number of the input was being
    >read".
    >
    >Then I might take this approach. Adjust my trap at the lowlevel so it
    >doesn't show and log the error, just updates the Err object and reraises.
    >e.g.
    >
    >GeneralError:
    > If Err.Number = 9 then
    > Err.Raise Err.Number, Err.Source, "Incorrect number of fields in
    >input record: &" Ubound(straData) & vbNewLine & Err.Description
    > Else
    > Call LOG_ShowError("frmDdayReptDialog Sub MyRoutine")
    > End if
    > Err.Raise 65535 ' quietly interrupt caller
    > Exit Sub
    >----
    >
    >When the caller feels the hit from error 9, its own error trap kicks in

    and
    >calls the standard LOG_ShowError. This time it will log and show the error
    >9. But it adds its own info to the Err.Description first e.g.
    > .....
    > "Error reading line: "& lngLineNumber & " of input file: " & strFilePath
    >& vbNewLine & Err.Description.
    > Call LOG_ShowError("frmDdayReptDialog Sub MyRoutine")
    > .....
    >
    >The error message is actually displayed and logged by the highest level

    of
    >caller that has useful info, but appends info from each level with something
    >to add. Above that, each routine on the stack probably just wants to quit
    >quietly while the user fixes things up, so the quiet error 65535 propogates.
    >
    >----
    >
    >Kathleen's question: why low level error handling?
    >
    > - to immediately identify the line causing the error with Erl.
    > (Next year I'll write code that never has bugs, but this year I still
    >wrote a few <!>.
    > Til then, I want to know exactly which line it was on, right away.
    >Life is too short, customers are too impatient )
    > - to provide best info. That's where the problem was, usually there's
    >useful information that the caller doesn't know.
    > - it's easy. Unless you don't automate it, so automate it!
    >
    >----
    >
    >Other EH trivia:
    >
    >---
    >
    >I've been using George ??'s VBBuilder to add line numbers during the Build
    >process, and Erl in the ShowError routine, if there is a bug I can find

    it
    >immediately. (He also has an automated error trap addin, but I use my
    >own.). I find this fast enough, and very convenient, even indispensible!
    >
    >Callstack: I find callstack remarkably NOT useful in my own experience for
    >finding problems. Very often something crucial to the problem happened

    in a
    >routine that is no longer on the stack. So I append in memory to a log

    of
    >key steps. (the <LOG_SessionString("frmDdayReptDialog Sub MyRoutine", "")
    >
    >call above) .
    >
    >The log gets dumped when an unexpected error is trapped. I find this better
    >myself, exactly why do people like the stack to dump?
    >
    >----
    >
    >Comments welcome, but I feel pretty satisfied that I've settled on simple
    >and productive error handling for corporate/LAN applications.
    >
    >Only problem, web apps and DNA change everything. I guess we are all still
    >coming to grips how to make that uniform, simple, productive. Not easy
    >since all the technology is changing so fast at every level!
    >
    >regards
    >Richard.
    >
    >
    >
    >



  3. #33
    Richard Curzon Guest

    Re: Correct Error Handling


    Michael Culley <m_culley@one.net.au> wrote in message
    news:391ea4a5$1@news.devx.com...
    >
    > Richard
    >
    > >>Exactly why do people like the stack to dump?

    >
    > Some routines you will know where the stack came from, so it won't be much
    > use. But if the routine that the error originated in is a very general

    routine
    > then the call could have come from a hundred places. Hence the call stack
    > will be useful.


    I'm not wondering so much why the stack is useful, but why would it be
    preferable to a call sequence log?

    I think a call sequence log shows where the call come from (the imediate
    stack), but it also shows info the stack doesn't.... the preceding calls
    that are no longer on the stack, and optionally any key state changes they
    made to the application that you log in passing.

    > One question I have regarding your approach. You call error handling code
    > to log each routine called before an error occurs. This means extra code
    > being run for every routine, and this extra code includes string

    manipulation
    > (which can be slow). Do you find this slows things down. Do you remove it
    > from procs that are called repeatedly or have another method of dealing

    with
    > speed?


    One of my oldie sayings, "where efficiency matters, just measure
    efficiency". Don't ever cut back on maintainability or standards because
    somebody says variants, or strings, or anything else in the toolbag, are
    "too slow for a pro".

    Cut back ONLY when you have proof it IS faster in your program, and
    significantly faster. Line Numbers: Adding line numbers may "bloat" your
    code by 15-20% if you do the entire program. For a corp desktop/LAN app, no
    problem.

    (Different story on web apps, where the CPU and memory may be shared for
    many users!)

    Say in another app you are looping100,000 times in some code, you probably
    wouldn't log every loop. It's too much info anyway! My "ring" structure
    log usually is initialized at 1000 items, after which older items overwrite.
    (The log that dumps on an error). There should be enough info in the last
    1000 messages to figure anything out, particularly when line numbers are
    there too.

    Any little tricks you find useful in error handling?

    regards
    Richard.



  4. #34
    Richard Curzon Guest

    Re: Correct Error Handling


    Kathleen Dollard-Joeris <kjoeris@noemailplease.com> wrote in message
    news:391e12e2@news.devx.com...
    > Richard!
    >
    > How long since we last argued??? For old times sake, at least, I gotta
    > disagree!
    >
    > First, and most sinfully you repeat the name of the sub twice! Bad, bad,
    > bad.


    Well I admit I do some bad things, I may not go to heaven. That's without
    even counting that sin though...

    You counting your bytes now, Katheen? I haven't done that since assembler
    days, when a lot of C and VB programmers still did it. Maybe you're doing
    published components more than me, but most of us are getting less anal
    about bytes, not more.

    There was a corporate project I was on a few years ago where all strings
    were put in constants files.

    Now, I do that sort of thing for a product that needs to be translated
    (except I use string resources)... but these guys just did it as a rule, it
    was "better". Sometimes you used strings, and partial strings twice. If
    you wanted to use a string, you first looked to see if somebody already had
    it, and you reused it.

    It drove a couple of us so crazy, the delay in looking up every single
    thing, and finding where a string came from. "You changed a shared string
    without telling everybody!"... We joked about a Hello World program written
    like:

    MsgBox gH & gE & gL & gL & gO & gSPACE & gW & wO & gR & gL & gD & gBANG

    Well maybe you had to be there...

    > Then you call a function called ShowError in every blasted sub. You either
    > have a badly named sub, or you show the error to your user way too many
    > times.


    I think we "disagreed" about this before. You didn't read my messge then
    either, tut tut.

    If ShowError receives an error of 65535, it shows nothing to the user. The
    only purpose of error 65535 is to make sure the calling routines stop when
    there's an error in a called sub.

    Once again, I'm getting less fussy about extra calls, etc. Unlike most
    people who complain to me about such things, I actually measure whether they
    matter!

    What I find is, these things never make a significant difference in timing
    tests. Or maybe in a few cases where there was a clear risk anyway, just
    cuz you're looping a 1,000,000 times, or making DCOM calls, or something
    else obvious. I build fairly large programs, current one just hit 50,000
    lines, no speed problems or other size issues.

    > Finally, no where here do you record the VB info on the error: just being
    > sloppy?


    But I do, now you're being sloppy! I know you're just busy, but why invest
    anytime in a discussion if you don't read what you comment on?!

    I mentioned using err info to append your own details to. Or maybe you
    expect to see the Err object in each error trap.

    What some people don't know is that in more recent VB, the error info is
    still in the Err object when you call a routine like ShowError. No need to
    capture and pass it separately. ShowError knows exactly what the problem
    was, even the line number is still available.

    (I think I first saw that in Visual Data if I remember a few versions back
    and it made me rethink some things)

    Mind you, there are a few times you have to be extra careful to preserve the
    error... maybe you have to do some cleanup before ShowError. I have an
    object that does that too, can be passed into ShowError.

    > may NOT be critical to the higher
    > level app. You are a lowly peon doing the work you were told to do!!!! You
    > do not have the right to complain!!!


    Slow down girl, you missed the example again!

    EG a file reading module: The high level routine knows what line number was
    being read, the low one can tell you the parsing issue. I showed a standard
    way of combining all the info into one message. The message is presented
    just once, by the highest level routine that has useful info. So why not
    do that?

    > I prefer to stuff the name at the start of the routine, although it can

    also
    > be done in an error handler (5 lines instead of 1).


    I did that once, but now I notice, have pretty much dropped it. Cuz often I
    only use the routine name once or twice...

    Some people (like those guys I mention above) just love indirection for it's
    own sake, they think it makes you look like more of a pro if you always have
    to follow references to find anything! The diff between what you do and
    what I do looks like small potatoes though. I'll probably always lean to
    avoiding indirection unless it serves a practical, measurable purpose!

    keep charging!
    Richard.



  5. #35
    Kathleen Dollard-Joeris Guest

    Re: Correct Error Handling

    Richard,

    > You counting your bytes now, Katheen? I haven't done that since assembler
    > days, when a lot of C and VB programmers still did it. Maybe you're doing
    > published components more than me, but most of us are getting less anal
    > about bytes, not more.


    I could care less about the bytes. I just sometimes change the names of
    things and would prefer to just have to fix it _once_! Just trying to avoid
    semi redundant code here.

    > MsgBox gH & gE & gL & gL & gO & gSPACE & gW & wO & gR & gL & gD & gBANG


    Your naming for O stinks. HTH. <g>

    > If ShowError receives an error of 65535, it shows nothing to the user.

    The
    > only purpose of error 65535 is to make sure the calling routines stop when
    > there's an error in a called sub.


    Then wouldn't it be better named

    ShowErrorUnlessErrorIs655335 ' or
    MaybeShowError

    > Once again, I'm getting less fussy about extra calls, etc. Unlike most
    > people who complain to me about such things, I actually measure whether

    they
    > matter!


    Tnank goodness calls are fast. You can afford to build a stack independent
    of error handling and make life a lot simpler.

    :> > Finally, no where here do you record the VB info on the error: just
    being
    > > sloppy?

    >
    > But I do, now you're being sloppy! I know you're just busy, but why

    invest
    > anytime in a discussion if you don't read what you comment on?!


    Actually I just learned/remembered something, I say as I wipe egg from my
    face. I am in the habit of passing around the error object. I just tested
    and it would be available to your Log function. I do prefer it when I learn
    something here without making a fool of myself.

    > EG a file reading module: The high level routine knows what line number

    was
    > being read, the low one can tell you the parsing issue. I showed a

    standard
    > way of combining all the info into one message. The message is presented
    > just once, by the highest level routine that has useful info. So why not
    > do that?


    Highest or lowest? It looks like you are presenting the error in the most
    deeply nested sub, the one where the error occurs. I absolutely agree with
    this for anticipated errors. For all anticipated errors, this the sub that
    knows the context. But let's say it is a math routine that has the
    possibility of divide by zero. This lowly routine displaying an error makes
    no sense to me. The calling function, or its calling function, or somewhere
    up the tree knows whether the error is important and what to do with it. For
    example, perhaps we do not want to log this error at all, but simply report
    the value as "ERR" if any kind of calculation error occurs.

    In most cases you just need one routine to do something with the error. I
    think that should be the routine that understands the context and big
    picture, not the one that knows the detail.

    > Some people (like those guys I mention above) just love indirection for

    it's
    > own sake, they think it makes you look like more of a pro if you always

    have
    > to follow references to find anything! The diff between what you do and
    > what I do looks like small potatoes though. I'll probably always lean to
    > avoiding indirection unless it serves a practical, measurable purpose!


    I am not suggesting indirection here. Well, maybe the module name. Something
    akin to the following

    Private Const MyModule = "MyModule"

    Public Sub MySub(sMyParam as String)

    CallStack.Add MyModule & "::MySub(" & sMyParam & ")"

    ' Do sub stuff here

    CallStack.Remove

    End Sub
    --
    Kathleen
    (MS-MVP)
    Reply in the newsgroup so everyone can benefit
    --




  6. #36
    Kathleen Dollard-Joeris Guest

    Re: Correct Error Handling

    How do you make your call sequence readable. It sounds like a really good
    idea, but I am not envisioning how you interpret something like the
    following

    Sub A
    Sub B
    Sub C
    Sub D

    Was Sub C called from Sub B or A. Sub D from A, B or C?

    I can see ways to keep this straight, but they require that you know when
    you leave a function, as well as when you enter it.

    --
    Kathleen
    (MS-MVP)
    Reply in the newsgroup so everyone can benefit
    --




  7. #37
    Karl E. Peterson Guest

    Re: Correct Error Handling

    Yeah, yeah, yeah... :-)
    --
    http://www.mvps.org/vb


    "Kathleen Dollard-Joeris" <kjoeris@noemailplease.com> wrote in message
    news:391e1078@news.devx.com...
    > Karl,
    >
    > > In retrospect, it's probably better to leave the cursor setting to a

    > seperate method.
    >
    > Yeah, it probably is, because otherwise the pup isn't going to work. If you
    > don't access your object declared as New, when is it going to get
    > instantiated?
    >
    > --
    > Kathleen
    > (MS-MVP)
    > Reply in the newsgroup so everyone can benefit
    > --
    >
    >
    >




  8. #38
    Mike Culley Guest

    Re: Correct Error Handling


    Richard,

    I understand what you are saying, but I would not use your method. It only
    my way of coding, but I try to code as efficiently as possible from the start,
    this make the app generally quicker - even if there is no speed issue it
    is better to have it run faster.

    Generally, I can find the error with just a call stack, or just the error
    and location. It may be harder to find, but that is a tradeoff.

    Michael Culley

    "Richard Curzon" <richardcurzon@home.com> wrote:
    >
    >Michael Culley <m_culley@one.net.au> wrote in message
    >news:391ea4a5$1@news.devx.com...
    >>
    >> Richard
    >>
    >> >>Exactly why do people like the stack to dump?

    >>
    >> Some routines you will know where the stack came from, so it won't be

    much
    >> use. But if the routine that the error originated in is a very general

    >routine
    >> then the call could have come from a hundred places. Hence the call stack
    >> will be useful.

    >
    >I'm not wondering so much why the stack is useful, but why would it be
    >preferable to a call sequence log?
    >
    >I think a call sequence log shows where the call come from (the imediate
    >stack), but it also shows info the stack doesn't.... the preceding calls
    >that are no longer on the stack, and optionally any key state changes they
    >made to the application that you log in passing.
    >
    >> One question I have regarding your approach. You call error handling code
    >> to log each routine called before an error occurs. This means extra code
    >> being run for every routine, and this extra code includes string

    >manipulation
    >> (which can be slow). Do you find this slows things down. Do you remove

    it
    >> from procs that are called repeatedly or have another method of dealing

    >with
    >> speed?

    >
    >One of my oldie sayings, "where efficiency matters, just measure
    >efficiency". Don't ever cut back on maintainability or standards because
    >somebody says variants, or strings, or anything else in the toolbag, are
    >"too slow for a pro".
    >
    >Cut back ONLY when you have proof it IS faster in your program, and
    >significantly faster. Line Numbers: Adding line numbers may "bloat" your
    >code by 15-20% if you do the entire program. For a corp desktop/LAN app,

    no
    >problem.
    >
    >(Different story on web apps, where the CPU and memory may be shared for
    >many users!)
    >
    >Say in another app you are looping100,000 times in some code, you probably
    >wouldn't log every loop. It's too much info anyway! My "ring" structure
    >log usually is initialized at 1000 items, after which older items overwrite.
    >(The log that dumps on an error). There should be enough info in the last
    >1000 messages to figure anything out, particularly when line numbers are
    >there too.
    >
    >Any little tricks you find useful in error handling?
    >
    >regards
    >Richard.
    >
    >



  9. #39
    Kathleen Dollard-Joeris Guest

    Re: Correct Error Handling

    Karl,

    When was the last time I caught you in even a little oversight?

    Better be careful or people will think you are a role model?

    --
    Kathleen
    (MS-MVP)
    Reply in the newsgroup so everyone can benefit
    --



  10. #40
    Karl E. Peterson Guest

    Re: Correct Error Handling

    Hi Kathleen --

    > When was the last time I caught you in even a little oversight?


    Errr..., dunno?

    > Better be careful or people will think you are a role model?


    Jeez, we can't have that! <g>

    Later... Karl
    --
    http://www.mvps.org/vb







  11. #41
    Richard Curzon Guest

    Re: Correct Error Handling


    Kathleen Dollard-Joeris <kjoeris@noemailplease.com> wrote in message
    news:3920047b@news.devx.com...
    >
    > ShowErrorUnlessErrorIs655335 ' or
    > MaybeShowError


    "MaybeShowError", I like it. Am I right, that suggestion shows you've read
    a little GNU code?! You can always tell somebody's literay influences
    <grin>...

    But I find there are a lot of VB project folks who don't have the GNU sense
    of humor, everytime I've named a function "Maybe...." I've complaints I til
    just took it out. <grin>. Look at the fuss over a couple of silly April
    Fools jokes, no sense of humor out there...

    The LOG module works like a Singleton that handles and logs errors. You can
    make tell it to ignore other error numbers as well as 65535, so
    MaybeShowError is not a bad name at all.

    > Actually I just learned/remembered something, I say as I wipe egg from my
    > face. I am in the habit of passing around the error object. I just tested
    > and it would be available to your Log function. I do prefer it when I

    learn
    > something here without making a fool of myself.


    No shame in it, I always find on every project a very good VB programmer who
    just hasn't got around to thinking it thru every change in VB lately, etc.
    Okay, sometimes the programmer is me <bg>

    > Highest or lowest? It looks like you are presenting the error in the most
    > deeply nested sub, the one where the error occurs.


    In the low level, I reraised the error with Err.Raise, while appending the
    local useful info to the Err.Description. That slaps the next higher stack
    routine across the face, "snap out of it", and that routine can do 2 things
    in it's trap. Either the same as the lower level (append information and
    reraise to it's caller in turn) or append info to Err.Description and call
    :LOG_ShowError.

    >I absolutely agree with
    > this for anticipated errors. For all anticipated errors, this the sub that
    > knows the context. But let's say it is a math routine that has the
    > possibility of divide by zero. This lowly routine displaying an error

    makes
    > no sense to me. The calling function, or its calling function, or

    somewhere
    > up the tree knows whether the error is important and what to do with it.

    For
    > example, perhaps we do not want to log this error at all, but simply

    report
    > the value as "ERR" if any kind of calculation error occurs.


    Good stuff. But I wonder about the distinction, anticipated vs
    unanticipated. It reminds me of the folks who can anticipate which C++
    functions need to be virtual and can be inherited, and which ones "no one
    will ever need". A few weeks later, different story.

    In this case, we "anticipate" a certain "unanticipated" error, like divide
    by zero. If that turned out to be the error, the assumption would probably
    work. but ...

    I'm still tring to write bug free code, first time, I haven't given up
    (Watts Humphrey thinks I should do it, so I wouldn't want to let him down!).

    So next program will be bug free for sure. Til then, I'll want to trap that
    error where it happened, with the line it happened on. I still get erros I
    didn't "anticipate"... there, that's my confession out!


    > CallStack.Add MyModule & "::MySub(" & sMyParam & ")"


    I wouldn't mind doing that, esp if I was doing it manually. The add-in does
    the extra work of inserting the details, so I happen to chose the clarity of
    a literal string, figure it saves.

    ----

    Okay, a little challenge to all who use CallStack or similar things...
    nobody wants to tell me why, so I'll assert one interpretation.

    I ASSERT, that this is just another case of C envy, the assumption of the VB
    rabble that whatever C programmers do, whatever coding habits they have,
    even whatever naming conventions they use, are bound to be "right", and
    should be mindlessly emulated.

    Callstack tracking is a case of mindless imitation. The C program dumps it,
    Java program dumps it, so the VB program should.

    What you really need is to log important state changes in your app, in
    memory, and dump that out on an error... not a callstack!
    If the CallStack tells you the info you need, it's just dumb luck.

    Excecute that ASSERT, what do you get ?! <g>




  12. #42
    Richard Curzon Guest

    Re: Correct Error Handling

    Practical terms, I find I don't often wonder exactly what's on the stack
    when an error happens.

    Suppose you have a routine that asks the user what he wants to divide by.
    "Zero" says the user. OK, close the form, try to divide. You have an
    error, but the input routine you called isn't on the stack.

    What you need is something like SUP_SessionLog("frmMain Sub Main, user
    divisor accepted:" & strAnswer). That would tell you what happened. All I
    showed in my example was the barebones logging of module and function, but
    usually I'd add to that.... to also show what args are passed in for
    example, or the state of the communication port, etc etc. And whenever an
    important state change happens, it goes to the in-memory session log too.

    Once in a while you might have a case where A calls B, and A calls C. But B
    could also call C.... For me, that's usually just my "well-debugged"
    logging calls!

    But in those cases, I have added logging code to various possible exit
    points to trace exactly what did happen. But practical terms, when the bug
    hits the fan, there just isn't much mystery around it.

    In fact 80% of the time, all I need from an error log is the line number the
    error happened on, and the exact error. The other 20% of the time, I might
    need some context, usually found in something that was logged earlier.

    But one could obviously could use an object like your CallStack to write to
    a session log when it's destroyed. So you'd get a kind of call stack
    tracking in the log (much better than a dump of the call stack, right?)
    along with any other stuff we logged in passing. hmmm I might try that!
    ..
    Kathleen Dollard-Joeris <kjoeris@noemailplease.com> wrote in message
    news:3920056a@news.devx.com...
    > How do you make your call sequence readable. It sounds like a really good
    > idea, but I am not envisioning how you interpret something like the
    > following
    >
    > Sub A
    > Sub B
    > Sub C
    > Sub D
    >
    > Was Sub C called from Sub B or A. Sub D from A, B or C?
    >
    > I can see ways to keep this straight, but they require that you know when
    > you leave a function, as well as when you enter it.
    >
    > --
    > Kathleen
    > (MS-MVP)
    > Reply in the newsgroup so everyone can benefit
    > --
    >
    >
    >




  13. #43
    Colin McGuigan Guest

    Re: Correct Error Handling

    Richard Curzon wrote in message <3921e4e1@news.devx.com>...
    >Okay, a little challenge to all who use CallStack or similar things...
    >nobody wants to tell me why, so I'll assert one interpretation.
    >
    >I ASSERT, that this is just another case of C envy, the assumption of the

    VB
    >rabble that whatever C programmers do, whatever coding habits they have,
    >even whatever naming conventions they use, are bound to be "right", and
    >should be mindlessly emulated.
    >
    >Callstack tracking is a case of mindless imitation. The C program dumps

    it,
    >Java program dumps it, so the VB program should.
    >
    >What you really need is to log important state changes in your app, in
    >memory, and dump that out on an error... not a callstack!
    >If the CallStack tells you the info you need, it's just dumb luck.
    >
    >Excecute that ASSERT, what do you get ?! <g>
    >


    Is CallStack this pill that will end all of our bug ills? Nah. Is it
    helpful even 50% of the time? Nah. In fact, in all my Java programming,
    the callstack dumped along with the error has only ever helped me twice.

    But, see. There's the kicker. It did help me twice. So I'd like the
    language to be able to dump it if necessary. Easy enough, IMHO. =)


    --
    Colin McGuigan




  14. #44
    Kathleen Dollard-Joeris Guest

    Re: Correct Error Handling

    Richard,

    Actually I have never done GNU. I think that notion came from McConnell.

    > In the low level, I reraised the error with Err.Raise, while appending the
    > local useful info to the Err.Description. That slaps the next higher

    stack
    > routine across the face, "snap out of it", and that routine can do 2

    things
    > in it's trap. Either the same as the lower level (append information and
    > reraise to it's caller in turn) or append info to Err.Description and

    call
    > :LOG_ShowError.


    I think I got thrown a bit in your example passing the name of the current
    routine, without appending it to the Err object (you use description or
    source). This is what I have historically done, but I no longer see any
    point in putting error handlers in routines that do not actually handle
    errors.

    > Good stuff. But I wonder about the distinction, anticipated vs
    > unanticipated. It reminds me of the folks who can anticipate which C++
    > functions need to be virtual and can be inherited, and which ones "no one
    > will ever need". A few weeks later, different story.


    Since I classify invalid parameters as unanticipated, I don't find this
    distinction hard.

    > So next program will be bug free for sure. Til then, I'll want to trap

    that
    > error where it happened, with the line it happened on. I still get erros

    I
    > didn't "anticipate"... there, that's my confession out!


    No it won't. It just doesn't have cost benefit. I keep striving too.
    Theprogrammer didn't cause the important bugs anyway, the design team did.

    > I wouldn't mind doing that, esp if I was doing it manually. The add-in

    does
    > the extra work of inserting the details, so I happen to chose the clarity

    of
    > a literal string, figure it saves.


    We've done the "Kathleen passionately hates code generators" stuff haven't
    we? And I really get annoyed when this cool Add-In tool gets used as a code
    generator. I mean if nothing else, how many extra bytes do you add to the
    EXE when there is a better way (I don't care about bytes when it is the best
    way. Such a cop-out Richard to blame the add-in!

    > Okay, a little challenge to all who use CallStack or similar things...
    > nobody wants to tell me why,


    It is easy and it is what people expect.

    I am actually going to try a call sequence in an app. If I get to it, I
    would like to record the data in a way that can seamlessly get either a call
    sequence or call stack.

    --
    Kathleen
    (MS-MVP)
    Reply in the newsgroup so everyone can benefit
    --



  15. #45
    Kathleen Dollard-Joeris Guest

    Re: Correct Error Handling

    Richard,

    I was just thinking the call sequence idea would be more useful if it
    indicated when a routine returned, and whether there was an error (we do
    swallow errors and they are sometimes the source of difficult to track bugs
    for me).

    --
    Kathleen
    (MS-MVP)
    Reply in the newsgroup so everyone can benefit
    --



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center