dcsimg


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 2 of 8 FirstFirst 1234 ... LastLast
Results 16 to 30 of 109

Thread: Correct Error Handling

  1. #16
    Mark Jerde Guest

    Re: Correct Error Handling

    Jim,

    > I still think this
    > is easier:


    In addition to Karl's remarks...

    I use an error-handling class based on the one in FMS's Total VB
    Sourcebook. I use CodeSMART to add the default error handling headers
    and footers to procedures. Here's a snip from an image-cropping form:

    Public Function a_AutoProcess() As Boolean
    100 On Error GoTo PROC_ERROR
    110 Dim curs As New clsSetCursor ' Safe hourglass ready
    120 Dim ProcPush As New CgErrPushPop
    130 ProcPush.Push "frmCrop.a_AutoProcess"


    The cursor class is dimmed on line 110. What could possibly be easier
    and more hassle-free than:

    curs.SetCursor

    just before starting a potentially-lengthy process?

    -- Mark

    P.S. The same concept is used for the class that pushes and pops the
    ModuleName.ProcedureName to & from the global error handler. (Lines
    120 & 130.) When I, the programmer, did the popping, occasionally (<g>)
    the stack would get unbalanced... VB's auto-scoping is more reliable,
    as well as easier. With CodeSMART, it's a selection on a popup menu.



  2. #17
    Jim Pragit Guest

    Re: Correct Error Handling


    If you're putting this every routine, you're needlessly setting the mousepointer
    over and over again, (not to mention the overhead of instantiating and destroying
    a COM object each time). Oh well, I'll give up trying to convince you.

    - Jim

    Mark Jerde <MJerdeIDT@compuserve.com> wrote:
    >Jim,
    >
    >> I still think this
    >> is easier:

    >
    >In addition to Karl's remarks...
    >
    >I use an error-handling class based on the one in FMS's Total VB
    >Sourcebook. I use CodeSMART to add the default error handling headers
    >and footers to procedures. Here's a snip from an image-cropping form:
    >
    >Public Function a_AutoProcess() As Boolean
    >100 On Error GoTo PROC_ERROR
    >110 Dim curs As New clsSetCursor ' Safe hourglass ready
    >120 Dim ProcPush As New CgErrPushPop
    >130 ProcPush.Push "frmCrop.a_AutoProcess"
    >
    >
    >The cursor class is dimmed on line 110. What could possibly be easier
    >and more hassle-free than:
    >
    > curs.SetCursor
    >
    >just before starting a potentially-lengthy process?
    >
    > -- Mark
    >
    >P.S. The same concept is used for the class that pushes and pops the
    >ModuleName.ProcedureName to & from the global error handler. (Lines
    >120 & 130.) When I, the programmer, did the popping, occasionally (<g>)


    >the stack would get unbalanced... VB's auto-scoping is more reliable,
    >as well as easier. With CodeSMART, it's a selection on a popup menu.



  3. #18
    John Perkins Guest

    Re: Correct Error Handling


    I just did a little test project that created a mousepointer class of my own
    that I use, set the cursor to the hourglass, set the cusor back to an arrow
    and destroyed the object... 100 times, far more than would be needed in most
    cases. It took about a blink of my eye.

    My rule of thumb is to never optimize before you know there is a problem
    and can prove it with a test. Go for elegance, then if it's necessary, optimize
    later after you identify a legitimate bottleneck.

    -John Perkins


    "Jim Pragit" <emunews@msn.com> wrote:
    >
    >If you're putting this every routine, you're needlessly setting the mousepointer
    >over and over again, (not to mention the overhead of instantiating and destroying
    >a COM object each time). Oh well, I'll give up trying to convince you.


    >
    >- Jim
    >
    >Mark Jerde <MJerdeIDT@compuserve.com> wrote:
    >>Jim,
    >>
    >>> I still think this
    >>> is easier:

    >>
    >>In addition to Karl's remarks...
    >>
    >>I use an error-handling class based on the one in FMS's Total VB
    >>Sourcebook. I use CodeSMART to add the default error handling headers


    >>and footers to procedures. Here's a snip from an image-cropping form:
    >>
    >>Public Function a_AutoProcess() As Boolean
    >>100 On Error GoTo PROC_ERROR
    >>110 Dim curs As New clsSetCursor ' Safe hourglass ready
    >>120 Dim ProcPush As New CgErrPushPop
    >>130 ProcPush.Push "frmCrop.a_AutoProcess"
    >>
    >>
    >>The cursor class is dimmed on line 110. What could possibly be easier


    >>and more hassle-free than:
    >>
    >> curs.SetCursor
    >>
    >>just before starting a potentially-lengthy process?
    >>
    >> -- Mark
    >>
    >>P.S. The same concept is used for the class that pushes and pops the
    >>ModuleName.ProcedureName to & from the global error handler. (Lines
    >>120 & 130.) When I, the programmer, did the popping, occasionally (<g>)

    >
    >>the stack would get unbalanced... VB's auto-scoping is more reliable,


    >>as well as easier. With CodeSMART, it's a selection on a popup menu.

    >



  4. #19
    John Perkins Guest

    Re: Correct Error Handling


    Just to add to and clarify my comment... you aren't going to be putting the
    mousepointer class in every routine, just those having to do with the UI.
    Class methods in your business logic (where most of your code should be)
    shouldn't have any code that deals with user interface elements.

    -John Perkins

    "John Perkins" <perk_j@yahoo.com> wrote:
    >
    >I just did a little test project that created a mousepointer class of my

    own
    >that I use, set the cursor to the hourglass, set the cusor back to an arrow
    >and destroyed the object... 100 times, far more than would be needed in

    most
    >cases. It took about a blink of my eye.
    >
    >My rule of thumb is to never optimize before you know there is a problem
    >and can prove it with a test. Go for elegance, then if it's necessary, optimize
    >later after you identify a legitimate bottleneck.
    >
    >-John Perkins
    >
    >
    >"Jim Pragit" <emunews@msn.com> wrote:
    >>
    >>If you're putting this every routine, you're needlessly setting the mousepointer
    >>over and over again, (not to mention the overhead of instantiating and

    destroying
    >>a COM object each time). Oh well, I'll give up trying to convince you.

    >
    >>
    >>- Jim
    >>
    >>Mark Jerde <MJerdeIDT@compuserve.com> wrote:
    >>>Jim,
    >>>
    >>>> I still think this
    >>>> is easier:
    >>>
    >>>In addition to Karl's remarks...
    >>>
    >>>I use an error-handling class based on the one in FMS's Total VB
    >>>Sourcebook. I use CodeSMART to add the default error handling headers

    >
    >>>and footers to procedures. Here's a snip from an image-cropping form:
    >>>
    >>>Public Function a_AutoProcess() As Boolean
    >>>100 On Error GoTo PROC_ERROR
    >>>110 Dim curs As New clsSetCursor ' Safe hourglass ready
    >>>120 Dim ProcPush As New CgErrPushPop
    >>>130 ProcPush.Push "frmCrop.a_AutoProcess"
    >>>
    >>>
    >>>The cursor class is dimmed on line 110. What could possibly be easier

    >
    >>>and more hassle-free than:
    >>>
    >>> curs.SetCursor
    >>>
    >>>just before starting a potentially-lengthy process?
    >>>
    >>> -- Mark
    >>>
    >>>P.S. The same concept is used for the class that pushes and pops the


    >>>ModuleName.ProcedureName to & from the global error handler. (Lines


    >>>120 & 130.) When I, the programmer, did the popping, occasionally (<g>)

    >>
    >>>the stack would get unbalanced... VB's auto-scoping is more reliable,

    >
    >>>as well as easier. With CodeSMART, it's a selection on a popup menu.

    >>

    >



  5. #20
    Mark Jerde Guest

    Re: Correct Error Handling

    Jim,

    > If you're putting this every routine, you're needlessly setting the mousepointer
    > over and over again, (not to mention the overhead of instantiating and destroying
    > a COM object each time).


    My understanding is

    Dim WhatEver As New CWhatEver

    doesn't _do_ anything; it just puts some more more code around

    WhatEver.DoSomething

    to create the object if necessary. VB handles it like this:

    If WhatEver Is Nothing Then
    Set WhatEver = New CWhatEver
    End If
    WhatEver.DoSomething


    > Oh well, I'll give up trying to convince you.


    Funny, lots of people have said that... <g>

    -- Mark


  6. #21
    Kathleen Dollard-Joeris Guest

    Re: Correct Error Handling

    Mark,

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


    Boy, that one brings back memories! :-)

    It can be used as

    Private Control_Event(Whatever)
    Dim oCursor as New CCursor ' This is the only place I use New

    oCursor = vbHourglass

    That's all there is too it folks!

    --
    Kathleen
    (MS-MVP)
    Reply in the newsgroup so everyone can benefit
    --
    Mark Jerde <MJerdeIDT@compuserve.com> wrote in message
    news:VA.000001af.045eab6f@dell-laptop...
    > Kenny & Jim,
    >
    > The best way I've found of handling the hourglass is from Deborah
    > Kurata's web site:
    >
    >
    >
    > 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
    >




  7. #22
    Kathleen Dollard-Joeris Guest

    Re: Correct Error Handling

    Karl,

    Does your initialize set the mousepointer to the hourglass or did you forget
    a line? The version on Deborah's site requires that the mousepointer be set
    (how my version works also)/

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



  8. #23
    Kathleen Dollard-Joeris Guest

    Re: Correct Error Handling

    Jim,

    > If you're putting this every routine, you're needlessly setting the

    mousepointer
    > over and over again, (not to mention the overhead of instantiating and

    destroying
    > a COM object each time). Oh well, I'll give up trying to convince you.


    Not every routine, just sub main and the events. It will very rarely be
    called more than once.

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



  9. #24
    Kathleen Dollard-Joeris Guest

    Re: Correct Error Handling

    Patrick,

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


    <snip>

    > ErrHandler:
    > LogError
    > Err.Raise (insert error info)


    So, I log my error an unknown number of times?

    Why not maintain a callstack, then allow VB to raise errors for
    unanticipated exceptions (I agree that anticipated exceptions should be
    handled close to the point of occurrence) through to the highest point that
    cares.

    I agree that each tier may need some error logging, if my business or data
    tiers are springing errors, I do not want to rely on the UI to tell me about
    it. But I don't see a purpose in including error handlingcode in every
    routine, assuming you have another plan for the callstack.

    Do you really see a purpose?

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



  10. #25
    Jim Pragit Guest

    Re: Correct Error Handling


    Kathleen,
    Alright, if you're only setting the mouse pointer in event procedures (and
    Sub Main), that's OK. What I was talking about was setting and resetting
    the mouse pointer in non-event procedures:

    Private Sub EventProcedure
    Screen.MousePointer = vbHourGlass

    Do While Not rs.EOF
    Call ProcessRS
    Loop

    Screen.MousePointer = vbDefault

    End Sub

    Private Sub ProcessRS
    Dim intMousePointer As Integer

    intMousePointer = Screen.MousePointer
    Screen.MousePointer = vbHourGlass

    'do something

    Screen.MousePointer = intMousePointer

    End Sub

    - Jim

    "Kathleen Dollard-Joeris" <kjoeris@noemailplease.com> wrote:
    >Jim,
    >
    >> If you're putting this every routine, you're needlessly setting the

    >mousepointer
    >> over and over again, (not to mention the overhead of instantiating and

    >destroying
    >> a COM object each time). Oh well, I'll give up trying to convince you.


    >
    >Not every routine, just sub main and the events. It will very rarely be
    >called more than once.
    >
    >--
    >Kathleen
    >(MS-MVP)
    >Reply in the newsgroup so everyone can benefit



  11. #26
    Karl E. Peterson Guest

    Re: Correct Error Handling

    Hi Kathleen --

    > Does your initialize set the mousepointer to the hourglass or did you forget
    > a line? The version on Deborah's site requires that the mousepointer be set
    > (how my version works also)/


    Guess you got me. <g> Been awhile since I used that class, but here (from the
    LVStyles.zip sample on my site) is the class in its entirety:

    Option Explicit

    Private m_nPointer As MousePointerConstants

    Public Sub ShowCursor(Optional nPointer As MousePointerConstants = vbHourglass)
    Screen.MousePointer = nPointer
    End Sub

    Private Sub Class_Initialize()
    m_nPointer = Screen.MousePointer
    End Sub

    Private Sub Class_Terminate()
    Screen.MousePointer = m_nPointer
    End Sub

    In retrospect, it's probably better to leave the cursor setting to a seperate method.

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






  12. #27
    Karl E. Peterson Guest

    Re: Correct Error Handling

    Hi Mark --

    > My understanding is
    >
    > Dim WhatEver As New CWhatEver
    >
    > doesn't _do_ anything;


    That's right. CWhatEver_Initialize won't fire until you make your first reference to
    one of its properties or methods.

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




  13. #28
    Ronald Dolman Guest

    Re: Correct Error Handling

    Kenny,

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

    point:

    You ALWAYS have one exit point! <g>

    Ronald



  14. #29
    Richard Curzon Guest

    Re: Correct Error Handling

    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.





  15. #30
    Kathleen Dollard-Joeris Guest

    Re: Correct Error Handling

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




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