DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 8 123 ... LastLast
Results 1 to 15 of 109

Thread: Correct Error Handling

  1. #1
    Mike Culley Guest

    Correct Error Handling


    Hi All,

    It seam the standard method of handling unexpected errors is to put an on
    error goto ErrorHandler at the start of each routine, log the error, etc.

    But my question is this. If you have a Function that gets called by another
    function (anything that is not an event) then you don't _have_ to put error
    handling in it - you can rely on the function calling it to trap the error.
    What does everyone do in this situation.

    TIA

    Michael Culley

  2. #2
    Mark Alexander Bertenshaw Guest

    Re: Correct Error Handling


    "Mike Culley" <m_culley@one.net.au> wrote:
    >It seems that the standard method of handling unexpected errors is to put

    an On
    >error goto ErrorHandler at the start of each routine, log the error, etc.
    >
    >But my question is this. If you have a Function that gets called by another
    >function (anything that is not an event) then you don't _have_ to put error
    >handling in it - you can rely on the function calling it to trap the error.
    >What does everyone do in this situation.


    Mike -

    The problem with this situation is that it causes an enormous jump down the
    call stack. If you always put an on error statement in every procedure, at
    least you can be sure that the error came from the statement immediately
    above. This allows you to build up a string representation of the call stack,
    if you wish.

    -------------------------
    Mark Alexander Bertenshaw
    Programmer/Analyst
    Prime Response
    Brentford
    UK


  3. #3
    Mark Alexander Bertenshaw Guest

    Re: Correct Error Handling


    Sorry, I also forgot to mention that you can write roll back type code if
    an error is raised in the immediate procedure.

    -------------------------
    Mark Alexander Bertenshaw
    Programmer/Analyst
    Prime Response
    Brentford
    UK

  4. #4
    Mark Jerde Guest

    Re: Correct Error Handling

    Mike,

    One of the best discussions of VB error handling I know of is from the
    book "Advanced MS Visual Basic 5". The chapter's title is "On Error
    GoTo ****".

    This book is available on MSDN:

    http://msdn.microsoft.com/library/bo...vnvb5/ch01.htm

    HTH

    -- Mark


  5. #5
    Patrick Escarcega Guest

    Re: Correct Error Handling

    Mike,

    In the perfect world every function would
    have its own error trap. The error would be
    logged and reraised and a call stack could be
    generated as suggested by Mark.

    But sometimes that just isn't possible. A lot
    of times when I am really rushed, I will do
    what you are suggesting, and allow calling
    functions to handle called function errors.

    I restrict this however to private members of an
    object.

    e.g.

    CFoo:
    Public Sub Bar()
    On Error Goto ErrHandler
    DoSomething
    Exit Sub
    ErrHandler:
    LogError
    Err.Raise (insert error info)
    End Sub
    Private Sub DoSomething()
    End Sub


    So all public interfaces should handle the error,
    but it's up to the object whether it exposes its
    call stack to the outside world in case of error.


    "Mike Culley" <m_culley@one.net.au> wrote in message
    news:3918e042$1@news.devx.com...
    > But my question is this. If you have a Function that gets called by

    another
    > function (anything that is not an event) then you don't _have_ to put

    error
    > handling in it - you can rely on the function calling it to trap the

    error.
    > What does everyone do in this situation.





  6. #6
    Jim Pragit Guest

    Re: Correct Error Handling


    "Mike Culley" <m_culley@one.net.au> wrote:
    <Snip!>
    >But my question is this. If you have a Function that gets called by another
    >function (anything that is not an event) then you don't _have_ to put error
    >handling in it - you can rely on the function calling it to trap the error.


    This is correct. All unhandled run-time errors automatically propagate up
    the call stack to an event procedure.

    >What does everyone do in this situation?


    First, it helps to distinguish between an expected error and an unexpected
    error. I almost always handle expected errors in the routine in which they
    occur. If an error is not expected, I raise the error up the call stack
    till it reaches the top-most procedure (an event procedure). The top-most
    procedure then catches the error, logs it and displays an error message.
    To simplify the code, I have an ActiveX DLL which I use to do the error
    reporting/logging.

    Generally speaking, my error handling looks something like this:

    Private Sub Command1_Click()
    On Error GoTo Err_Handler

    Call DoSomething

    Err_Handler:
    If Err.Number = 1 Then
    'handle expected error
    Else
    Call AddToCallStack(Me.Name, "Command1_Click")
    Call ErrorReport
    End If
    End Sub

    Private Sub DoSomething()
    On Error GoTo Err_Handler

    'do something

    Err_Handler:
    If Err.Number = 2 Then
    'handle expected error
    Else
    Call AddToCallStack(Me.Name, "DoSomething")
    Err.Raise Err.Number
    End If
    End Sub

    Both AddToCallStack and ErrorReport are part of my error handling DLL. AddToCallStack
    maintains the call stack. ErrorReport does the error logging and message
    box.

    As you've pointed out, you really don't need error handling in non-event
    procedures, but I find that it helpful to keep track of where the error occurs.


    BTW, technically, there is one exception to the rule that all unhandled errors
    propagate up the call stack to an event procedure. That exception is when
    you use Sub Main as your start up object. In this case, there is no top-level
    event procedure.

    - Jim

  7. #7
    Jim Pragit Guest

    Re: Correct Error Handling


    >All unhandled run-time errors automatically propagate up
    >the call stack to an event procedure.


    Just to be clear, all routines you write are always called either directly
    or indirectly by an event procedure (or Sub Main).

    As an aside, this principle can also be applied to setting the hourglass.
    I used to work on one project where the standard convention would be to
    save the mouse pointer as soon as you entered a routine and then change it
    to an hourglass. When the routine was over, you change the mouse pointer
    back to the original value. If we had a call stack that was 10 levels deep,
    it would do this setting and resetting of the mouse pointer 10 times. If
    there was a loop involved, the mouse pointer would be changed thousands upon
    thousands of times. Although this works, it's messy and technically will
    slow down your program. Since all code begins with an event, it's much cleaner
    to just set the mouse pointer in the event procedure and be done with it.


    - Jim


  8. #8
    Jason Bock Guest

    Re: Correct Error Handling


    "Jim Pragit" <James.Pragit@BakerNet.com> wrote in message
    news:3919b1af$1@news.devx.com...
    >
    > As an aside, this principle can also be applied to setting the hourglass.
    > I used to work on one project where the standard convention would be to
    > save the mouse pointer as soon as you entered a routine and then change it
    > to an hourglass. When the routine was over, you change the mouse pointer
    > back to the original value. If we had a call stack that was 10 levels

    deep,
    > it would do this setting and resetting of the mouse pointer 10 times. If
    > there was a loop involved, the mouse pointer would be changed thousands

    upon
    > thousands of times. Although this works, it's messy and technically will
    > slow down your program. Since all code begins with an event, it's much

    cleaner
    > to just set the mouse pointer in the event procedure and be done with it.


    Funny, I've done that myself . The reason I do the "store-and-reset" is
    for the following reason. Say you have a method like this:


    Sub SomeMethod()

    Screen.MousePointer = vbHourglass

    End Sub


    Now you add error handling and (gasp!) you throw an error:


    Sub SomeMethod()

    On Error Goto Error_SomeMethod

    Screen.MousePointer = vbHourglass

    Exit Sub

    Error_SomeMethod:

    End Sub


    Since the mousepointer is still an hourglass, you may end up showing the
    error message via a message box and the hourglass pointer will confuse the
    end user.

    You could simplify this by creating a module called MSHandler:


    Private mlngMS As Long

    Public Sub Alter(NewValue As Long)

    mlngMS = Screen.MousePointer
    Screen.MousePointer = NewValue

    End Sub

    Public Sub Restore()

    Screen.MousePointer = mlngMS

    End Sub


    Then, in your code you could do this:


    Sub SomeMethod()

    On Error Goto Error_SomeMethod

    MSHandler.Alter vbHourglass

    MSHandler.Restore

    Exit Sub

    Error_SomeMethod:

    MSHandler.Restore

    End Sub


    Granted, it's still a pain in the butt, but this could be set up via a
    procedure generator and now you don't need a Long variable in every
    procedure to persist the mouse pointer state. Plus, this should only exist
    in form code; non-UI components should NOT change the mouse pointer. That's
    a decision for the presentation layer. Of course, if you have the time, use
    Keith Brown's universal delegator to do the pre- and post- mouse pointer
    altering for you .

    Regards,

    Jason



  9. #9
    Jim Pragit Guest

    Re: Correct Error Handling


    Jason,

    Correct me if I'm wrong, but when the MsgBox is displayed, the MsgBox automatically
    gets the focus. The mouse pointer becomes vbDefault while the mouse is over
    the MsgBox. The mouse pointer is an hourglass when its over the calling
    form, but I don't see how this hurts because the calling form is disabled
    anyway. I don't find this confusing.

    But if this is what bothers you, how about something like this:

    Private Sub Form_Click()
    On Error GoTo Err_Handler

    Screen.MousePointer = vbHourglass

    Call DoSomething

    Screen.MousePointer = vbDefault

    Exit Sub

    Err_Handler:
    MsgBox Err.Description
    Screen.MousePointer = vbDefault
    End Sub

    Private Sub DoSomething()
    On Error GoTo Err_Handler

    Err.Raise 5

    Exit Sub

    Err_Handler:
    Dim intMousePointer As Integer
    intMousePointer = Screen.MousePointer
    Screen.MousePointer = vbDefault
    MsgBox Err.Description
    Screen.MousePointer = intMousePointer
    End Sub

    This way, you're only playing with the mouse pointer when you need to (i.e.
    when displaying a MsgBox). Unless you're writing code to display an MsgBox
    in every routine, this should cut down on the mouse setting/resetting code
    considerably. That way, if you have a call stack 10 levels deep but only
    2 routines display a MsgBox, you only have to include the setting/resetting
    code in those 2 routines.

    - Jim

    "Jason Bock" <jrbock@execpc.com> wrote:
    >
    >"Jim Pragit" <James.Pragit@BakerNet.com> wrote in message
    >news:3919b1af$1@news.devx.com...
    >>
    >> As an aside, this principle can also be applied to setting the hourglass.
    >> I used to work on one project where the standard convention would be

    to
    >> save the mouse pointer as soon as you entered a routine and then change

    it
    >> to an hourglass. When the routine was over, you change the mouse pointer
    >> back to the original value. If we had a call stack that was 10 levels

    >deep,
    >> it would do this setting and resetting of the mouse pointer 10 times.

    If
    >> there was a loop involved, the mouse pointer would be changed thousands

    >upon
    >> thousands of times. Although this works, it's messy and technically will
    >> slow down your program. Since all code begins with an event, it's much

    >cleaner
    >> to just set the mouse pointer in the event procedure and be done with

    it.
    >
    >Funny, I've done that myself . The reason I do the "store-and-reset"

    is
    >for the following reason. Say you have a method like this:
    >
    >
    >Sub SomeMethod()
    >
    >Screen.MousePointer = vbHourglass
    >
    >End Sub
    >
    >
    >Now you add error handling and (gasp!) you throw an error:
    >
    >
    >Sub SomeMethod()
    >
    >On Error Goto Error_SomeMethod
    >
    >Screen.MousePointer = vbHourglass
    >
    >Exit Sub
    >
    >Error_SomeMethod:
    >
    >End Sub
    >
    >
    >Since the mousepointer is still an hourglass, you may end up showing the
    >error message via a message box and the hourglass pointer will confuse the
    >end user.
    >
    >You could simplify this by creating a module called MSHandler:
    >
    >
    >Private mlngMS As Long
    >
    >Public Sub Alter(NewValue As Long)
    >
    >mlngMS = Screen.MousePointer
    >Screen.MousePointer = NewValue
    >
    >End Sub
    >
    >Public Sub Restore()
    >
    >Screen.MousePointer = mlngMS
    >
    >End Sub
    >
    >
    >Then, in your code you could do this:
    >
    >
    >Sub SomeMethod()
    >
    >On Error Goto Error_SomeMethod
    >
    >MSHandler.Alter vbHourglass
    >
    >MSHandler.Restore
    >
    >Exit Sub
    >
    >Error_SomeMethod:
    >
    >MSHandler.Restore
    >
    >End Sub
    >
    >
    >Granted, it's still a pain in the butt, but this could be set up via a
    >procedure generator and now you don't need a Long variable in every
    >procedure to persist the mouse pointer state. Plus, this should only exist
    >in form code; non-UI components should NOT change the mouse pointer. That's
    >a decision for the presentation layer. Of course, if you have the time,

    use
    >Keith Brown's universal delegator to do the pre- and post- mouse pointer
    >altering for you .
    >
    >Regards,
    >
    >Jason



  10. #10
    Kenny Acock Guest

    Re: Correct Error Handling


    The problem is a little easier if you make sure you have only one exit point:

    Private MySub()
    On Error Goto MyErrorHandler
    Dim lPointer As Long
    lPointer = Screen.MousePointer
    Screen.MousePointer = vbHourglass
    ...Do Stuff Here

    ExitSub:
    Screen.MousePointer = lPointer
    Exit Sub

    MyErrorHandler
    MsgBox Err.Description
    Resume ExitSub
    End Sub

    This is a better habit because you always know where the exit point is, so
    you can add code that will always execute as the sub, function, or property
    is exiting.

    Kenny Acock
    Teacher's Pal, Inc.
    kennya@teacherspal.com


    "Jim Pragit" <James.Pragit@BakerNet.com> wrote:
    >
    >Jason,
    >
    >Correct me if I'm wrong, but when the MsgBox is displayed, the MsgBox automatically
    >gets the focus. The mouse pointer becomes vbDefault while the mouse is

    over
    >the MsgBox. The mouse pointer is an hourglass when its over the calling
    >form, but I don't see how this hurts because the calling form is disabled
    >anyway. I don't find this confusing.
    >
    >But if this is what bothers you, how about something like this:
    >
    >Private Sub Form_Click()
    > On Error GoTo Err_Handler
    >
    > Screen.MousePointer = vbHourglass
    >
    > Call DoSomething
    >
    > Screen.MousePointer = vbDefault
    >
    > Exit Sub
    >
    >Err_Handler:
    > MsgBox Err.Description
    > Screen.MousePointer = vbDefault
    >End Sub
    >
    >Private Sub DoSomething()
    > On Error GoTo Err_Handler
    >
    > Err.Raise 5
    >
    > Exit Sub
    >
    >Err_Handler:
    > Dim intMousePointer As Integer
    > intMousePointer = Screen.MousePointer
    > Screen.MousePointer = vbDefault
    > MsgBox Err.Description
    > Screen.MousePointer = intMousePointer
    >End Sub
    >
    >This way, you're only playing with the mouse pointer when you need to (i.e.
    >when displaying a MsgBox). Unless you're writing code to display an MsgBox
    >in every routine, this should cut down on the mouse setting/resetting code
    >considerably. That way, if you have a call stack 10 levels deep but only
    >2 routines display a MsgBox, you only have to include the setting/resetting
    >code in those 2 routines.
    >
    >- Jim
    >
    >"Jason Bock" <jrbock@execpc.com> wrote:
    >>
    >>"Jim Pragit" <James.Pragit@BakerNet.com> wrote in message
    >>news:3919b1af$1@news.devx.com...
    >>>
    >>> As an aside, this principle can also be applied to setting the hourglass.
    >>> I used to work on one project where the standard convention would be

    >to
    >>> save the mouse pointer as soon as you entered a routine and then change

    >it
    >>> to an hourglass. When the routine was over, you change the mouse pointer
    >>> back to the original value. If we had a call stack that was 10 levels

    >>deep,
    >>> it would do this setting and resetting of the mouse pointer 10 times.

    > If
    >>> there was a loop involved, the mouse pointer would be changed thousands

    >>upon
    >>> thousands of times. Although this works, it's messy and technically

    will
    >>> slow down your program. Since all code begins with an event, it's much

    >>cleaner
    >>> to just set the mouse pointer in the event procedure and be done with

    >it.
    >>
    >>Funny, I've done that myself . The reason I do the "store-and-reset"

    >is
    >>for the following reason. Say you have a method like this:
    >>
    >>
    >>Sub SomeMethod()
    >>
    >>Screen.MousePointer = vbHourglass
    >>
    >>End Sub
    >>
    >>
    >>Now you add error handling and (gasp!) you throw an error:
    >>
    >>
    >>Sub SomeMethod()
    >>
    >>On Error Goto Error_SomeMethod
    >>
    >>Screen.MousePointer = vbHourglass
    >>
    >>Exit Sub
    >>
    >>Error_SomeMethod:
    >>
    >>End Sub
    >>
    >>
    >>Since the mousepointer is still an hourglass, you may end up showing the
    >>error message via a message box and the hourglass pointer will confuse

    the
    >>end user.
    >>
    >>You could simplify this by creating a module called MSHandler:
    >>
    >>
    >>Private mlngMS As Long
    >>
    >>Public Sub Alter(NewValue As Long)
    >>
    >>mlngMS = Screen.MousePointer
    >>Screen.MousePointer = NewValue
    >>
    >>End Sub
    >>
    >>Public Sub Restore()
    >>
    >>Screen.MousePointer = mlngMS
    >>
    >>End Sub
    >>
    >>
    >>Then, in your code you could do this:
    >>
    >>
    >>Sub SomeMethod()
    >>
    >>On Error Goto Error_SomeMethod
    >>
    >>MSHandler.Alter vbHourglass
    >>
    >>MSHandler.Restore
    >>
    >>Exit Sub
    >>
    >>Error_SomeMethod:
    >>
    >>MSHandler.Restore
    >>
    >>End Sub
    >>
    >>
    >>Granted, it's still a pain in the butt, but this could be set up via a
    >>procedure generator and now you don't need a Long variable in every
    >>procedure to persist the mouse pointer state. Plus, this should only exist
    >>in form code; non-UI components should NOT change the mouse pointer. That's
    >>a decision for the presentation layer. Of course, if you have the time,

    >use
    >>Keith Brown's universal delegator to do the pre- and post- mouse pointer
    >>altering for you .
    >>
    >>Regards,
    >>
    >>Jason

    >



  11. #11
    Jim Pragit Guest

    Re: Correct Error Handling


    Kenny,
    I'm not sure if you're addressing this to me or to Jason. If to me,

    my point was that you don't have to set/reset the mouse pointer in
    every single routine.

    - Jim

    "Kenny Acock" <kennya@teacherspal.com> wrote:
    >
    >The problem is a little easier if you make sure you have only one exit point:
    >
    >Private MySub()
    > On Error Goto MyErrorHandler
    > Dim lPointer As Long
    > lPointer = Screen.MousePointer
    > Screen.MousePointer = vbHourglass
    > ...Do Stuff Here
    >
    >ExitSub:
    > Screen.MousePointer = lPointer
    > Exit Sub
    >
    >MyErrorHandler
    > MsgBox Err.Description
    > Resume ExitSub
    >End Sub
    >
    >This is a better habit because you always know where the exit point is,

    so
    >you can add code that will always execute as the sub, function, or property
    >is exiting.
    >
    >Kenny Acock
    >Teacher's Pal, Inc.
    >kennya@teacherspal.com
    >
    >
    >"Jim Pragit" <James.Pragit@BakerNet.com> wrote:
    >>
    >>Jason,
    >>
    >>Correct me if I'm wrong, but when the MsgBox is displayed, the MsgBox automatically
    >>gets the focus. The mouse pointer becomes vbDefault while the mouse is

    >over
    >>the MsgBox. The mouse pointer is an hourglass when its over the calling
    >>form, but I don't see how this hurts because the calling form is disabled
    >>anyway. I don't find this confusing.
    >>
    >>But if this is what bothers you, how about something like this:
    >>
    >>Private Sub Form_Click()
    >> On Error GoTo Err_Handler
    >>
    >> Screen.MousePointer = vbHourglass
    >>
    >> Call DoSomething
    >>
    >> Screen.MousePointer = vbDefault
    >>
    >> Exit Sub
    >>
    >>Err_Handler:
    >> MsgBox Err.Description
    >> Screen.MousePointer = vbDefault
    >>End Sub
    >>
    >>Private Sub DoSomething()
    >> On Error GoTo Err_Handler
    >>
    >> Err.Raise 5
    >>
    >> Exit Sub
    >>
    >>Err_Handler:
    >> Dim intMousePointer As Integer
    >> intMousePointer = Screen.MousePointer
    >> Screen.MousePointer = vbDefault
    >> MsgBox Err.Description
    >> Screen.MousePointer = intMousePointer
    >>End Sub
    >>
    >>This way, you're only playing with the mouse pointer when you need to (i.e.
    >>when displaying a MsgBox). Unless you're writing code to display an MsgBox
    >>in every routine, this should cut down on the mouse setting/resetting code
    >>considerably. That way, if you have a call stack 10 levels deep but only
    >>2 routines display a MsgBox, you only have to include the setting/resetting
    >>code in those 2 routines.
    >>
    >>- Jim
    >>
    >>"Jason Bock" <jrbock@execpc.com> wrote:
    >>>
    >>>"Jim Pragit" <James.Pragit@BakerNet.com> wrote in message
    >>>news:3919b1af$1@news.devx.com...
    >>>>
    >>>> As an aside, this principle can also be applied to setting the hourglass.
    >>>> I used to work on one project where the standard convention would be

    >>to
    >>>> save the mouse pointer as soon as you entered a routine and then change

    >>it
    >>>> to an hourglass. When the routine was over, you change the mouse pointer
    >>>> back to the original value. If we had a call stack that was 10 levels
    >>>deep,
    >>>> it would do this setting and resetting of the mouse pointer 10 times.

    >> If
    >>>> there was a loop involved, the mouse pointer would be changed thousands
    >>>upon
    >>>> thousands of times. Although this works, it's messy and technically

    >will
    >>>> slow down your program. Since all code begins with an event, it's much
    >>>cleaner
    >>>> to just set the mouse pointer in the event procedure and be done with

    >>it.
    >>>
    >>>Funny, I've done that myself . The reason I do the "store-and-reset"

    >>is
    >>>for the following reason. Say you have a method like this:
    >>>
    >>>
    >>>Sub SomeMethod()
    >>>
    >>>Screen.MousePointer = vbHourglass
    >>>
    >>>End Sub
    >>>
    >>>
    >>>Now you add error handling and (gasp!) you throw an error:
    >>>
    >>>
    >>>Sub SomeMethod()
    >>>
    >>>On Error Goto Error_SomeMethod
    >>>
    >>>Screen.MousePointer = vbHourglass
    >>>
    >>>Exit Sub
    >>>
    >>>Error_SomeMethod:
    >>>
    >>>End Sub
    >>>
    >>>
    >>>Since the mousepointer is still an hourglass, you may end up showing the
    >>>error message via a message box and the hourglass pointer will confuse

    >the
    >>>end user.
    >>>
    >>>You could simplify this by creating a module called MSHandler:
    >>>
    >>>
    >>>Private mlngMS As Long
    >>>
    >>>Public Sub Alter(NewValue As Long)
    >>>
    >>>mlngMS = Screen.MousePointer
    >>>Screen.MousePointer = NewValue
    >>>
    >>>End Sub
    >>>
    >>>Public Sub Restore()
    >>>
    >>>Screen.MousePointer = mlngMS
    >>>
    >>>End Sub
    >>>
    >>>
    >>>Then, in your code you could do this:
    >>>
    >>>
    >>>Sub SomeMethod()
    >>>
    >>>On Error Goto Error_SomeMethod
    >>>
    >>>MSHandler.Alter vbHourglass
    >>>
    >>>MSHandler.Restore
    >>>
    >>>Exit Sub
    >>>
    >>>Error_SomeMethod:
    >>>
    >>>MSHandler.Restore
    >>>
    >>>End Sub
    >>>
    >>>
    >>>Granted, it's still a pain in the butt, but this could be set up via a
    >>>procedure generator and now you don't need a Long variable in every
    >>>procedure to persist the mouse pointer state. Plus, this should only

    exist
    >>>in form code; non-UI components should NOT change the mouse pointer.

    That's
    >>>a decision for the presentation layer. Of course, if you have the time,

    >>use
    >>>Keith Brown's universal delegator to do the pre- and post- mouse pointer
    >>>altering for you .
    >>>
    >>>Regards,
    >>>
    >>>Jason



  12. #12
    Mike Culley Guest

    Re: Correct Error Handling


    Jim, Mark B, Mark J, Patrick

    Thanks.
    This makes alot of sense.

    Michael Culley


    "Jim Pragit" <James.Pragit@BakerNet.com> wrote:
    >
    >"Mike Culley" <m_culley@one.net.au> wrote:
    ><Snip!>
    >>But my question is this. If you have a Function that gets called by another
    >>function (anything that is not an event) then you don't _have_ to put error
    >>handling in it - you can rely on the function calling it to trap the error.

    >
    >This is correct. All unhandled run-time errors automatically propagate up
    >the call stack to an event procedure.
    >
    >>What does everyone do in this situation?

    >
    >First, it helps to distinguish between an expected error and an unexpected
    >error. I almost always handle expected errors in the routine in which they
    >occur. If an error is not expected, I raise the error up the call stack
    >till it reaches the top-most procedure (an event procedure). The top-most
    >procedure then catches the error, logs it and displays an error message.
    > To simplify the code, I have an ActiveX DLL which I use to do the error
    >reporting/logging.
    >
    >Generally speaking, my error handling looks something like this:
    >
    >Private Sub Command1_Click()
    > On Error GoTo Err_Handler
    >
    > Call DoSomething
    >
    >Err_Handler:
    > If Err.Number = 1 Then
    > 'handle expected error
    > Else
    > Call AddToCallStack(Me.Name, "Command1_Click")
    > Call ErrorReport
    > End If
    >End Sub
    >
    >Private Sub DoSomething()
    > On Error GoTo Err_Handler
    >
    > 'do something
    >
    >Err_Handler:
    > If Err.Number = 2 Then
    > 'handle expected error
    > Else
    > Call AddToCallStack(Me.Name, "DoSomething")
    > Err.Raise Err.Number
    > End If
    >End Sub
    >
    >Both AddToCallStack and ErrorReport are part of my error handling DLL.

    AddToCallStack
    >maintains the call stack. ErrorReport does the error logging and message
    >box.
    >
    >As you've pointed out, you really don't need error handling in non-event
    >procedures, but I find that it helpful to keep track of where the error

    occurs.
    >
    >
    >BTW, technically, there is one exception to the rule that all unhandled

    errors
    >propagate up the call stack to an event procedure. That exception is when
    >you use Sub Main as your start up object. In this case, there is no top-level
    >event procedure.
    >
    >- Jim



  13. #13
    Mark Jerde Guest

    Re: Correct Error Handling

    Kenny & Jim,

    The best way I've found of handling the hourglass is from Deborah
    Kurata's web site:

    http://www.insteptech.com/VBForms.htm#Win_MousePointer


    The trouble with the "single exit point" theory is everything gets
    screwed up if you ever don't leave by that exit point... ;-)
    Having the mousepointer reset itself when a class goes out of scope for
    whatever reason is so much easier.

    -- Mark


  14. #14
    Jim Pragit Guest

    Re: Correct Error Handling


    Mark,
    I've seen that method before, but I still think this
    is easier:

    'w/ error handling
    Sub Control_Event
    On Error Goto Err_Handler

    Screen.MousePointer = vbHourglass

    'do something

    Screen.MousePointer = vbDefault

    Exit Sub
    Err_Handler:
    'do something
    Screen.MousePointer = vbDefault
    End Sub

    'or w/o error handling
    Sub Control_Event
    Screen.MousePointer = vbHourglass

    'do something

    Screen.MousePointer = vbDefault
    End Sub

    It's clean and it's simple. I suppose if you have
    more than one error handler per routine, the
    class method might save you some code, but I
    rarely have more than one per routine.

    - Jim

    Mark Jerde <MJerdeIDT@compuserve.com> wrote:
    >Kenny & Jim,
    >
    >The best way I've found of handling the hourglass is from Deborah
    >Kurata's web site:
    >
    >http://www.insteptech.com/VBForms.htm#Win_MousePointer
    >
    >
    >The trouble with the "single exit point" theory is everything gets
    >screwed up if you ever don't leave by that exit point... ;-)
    >Having the mousepointer reset itself when a class goes out of scope for


    >whatever reason is so much easier.
    >
    > -- Mark



  15. #15
    Karl E. Peterson Guest

    Re: Correct Error Handling

    Hi Jim --

    > It's clean and it's simple. I suppose if you have
    > more than one error handler per routine, the
    > class method might save you some code, but I
    > rarely have more than one per routine.


    That's not the point, so to speak. <g> When we wrote that, the idea was to
    "set-and-forget." All you do is drop the class creation into code, and things be
    cool from that point on:

    'w/ error handling
    Sub Control_Event
    Dim cur As New CMousePointer

    On Error Goto Err_Handler
    'do something
    Exit Sub
    Err_Handler:
    'do something
    End Sub

    See how much simpler that is? Plus!, the class method has the benefit of acting like
    an automatic stack, as each called procedure is free to set the cursor as needed, and
    there's never any fear of things getting out of sync (as when the Jr. Dev. decides to
    ExitSub w/o permission <g>).

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



    "Jim Pragit" <emunews@msn.com> wrote in message news:391abf5b$1@news.devx.com...
    >
    > Mark,
    > I've seen that method before, but I still think this
    > is easier:
    >
    > 'w/ error handling
    > Sub Control_Event
    > On Error Goto Err_Handler
    >
    > Screen.MousePointer = vbHourglass
    >
    > 'do something
    >
    > Screen.MousePointer = vbDefault
    >
    > Exit Sub
    > Err_Handler:
    > 'do something
    > Screen.MousePointer = vbDefault
    > End Sub
    >
    > 'or w/o error handling
    > Sub Control_Event
    > Screen.MousePointer = vbHourglass
    >
    > 'do something
    >
    > Screen.MousePointer = vbDefault
    > End Sub
    >
    > It's clean and it's simple. I suppose if you have
    > more than one error handler per routine, the
    > class method might save you some code, but I
    > rarely have more than one per routine.
    >
    > - Jim
    >
    > Mark Jerde <MJerdeIDT@compuserve.com> wrote:
    > >Kenny & Jim,
    > >
    > >The best way I've found of handling the hourglass is from Deborah
    > >Kurata's web site:
    > >
    > >http://www.insteptech.com/VBForms.htm#Win_MousePointer
    > >
    > >
    > >The trouble with the "single exit point" theory is everything gets
    > >screwed up if you ever don't leave by that exit point... ;-)
    > >Having the mousepointer reset itself when a class goes out of scope for

    >
    > >whatever reason is so much easier.
    > >
    > > -- Mark

    >




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