'On Error Goto' versus 'Try, Catch, Fail' - Page 2


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 2 of 2 FirstFirst 12
Results 16 to 22 of 22

Thread: 'On Error Goto' versus 'Try, Catch, Fail'

  1. #16
    Mike Mitchell Guest

    Re: 'On Error Goto' versus 'Try, Catch, Fail'

    On 9 Sep 2002 11:37:18 -0700, "Jason " <jason@hotmail.com> wrote:

    > Let's just say that it has some major problems, okay?


    Not with me, it didn't.

    MM

  2. #17
    Eddie Burdak Guest

    Re: 'On Error Goto' versus 'Try, Catch, Fail'

    Tim,

    Tim Overbay wrote:
    > Bull! The easiest way to lose your train of thought while reading
    > code is by using a goto statement, period.


    Well I find theeasiest way to lose train of thought is by handling the
    errors instead of concentrating on what the code is suppose to do. But
    I guess thats just me.

    But M$ has introduced it now thats fair do's -why oh why did they not
    get rid of On Error - dont get me wrong I'm sure they will and once I
    get to grips with .Net my error trapping will be using Try Catch
    Final.

    Eddie



  3. #18
    Eddie Burdak Guest

    Re: 'On Error Goto' versus 'Try, Catch, Fail'

    Jason,
    Jason wrote:
    <Snip>
    > But isn't this kind of beyond the scope of scripting? I mean, how
    > many new programmers put error traps in every routine they create,

    or
    > even any of them? Should they be required to?
    >
    > The answer, of course, is "no," but if you use VB-classic, the ONLY
    > way to determine where the error occurred is to rig every function.
    > I'm sorry, but that is just a nightmare to try to maintain. It
    > litters up the code something awful.


    Yes the end user of the code is somewhat buggered unless you put in a
    facility to do a log file or deep error cataching - no denying that.

    > In VB.NET, if you don't have an error trap, the next routine in the
    > call stack gets the error. If you don't have any error traps, you
    > can still tell which line of code caused your program to fail.


    I'll look forward to that when I get there (I'm working on it . NET
    that is).

    > So with VB.NET, you can get the same effect of adding "idiot-proof"
    > error traps to every function simply by doing nothing. To me, that
    > is a LOT SIMPLER for new users.


    Ah for the programmer yes. But for the end user of the program - well
    no.

    Also as the programmer dont you still need the input and conditions
    that not only caused the error but also led to it? Now assuming its
    not a gross error - by that I mean an oversight which can be corrected
    immediatly - then wont you need to know why the program did what it
    did and enter a debugging session yourself - i.e what the user did and
    what data they were working with? In this respect I always thought the
    VB6 IDE was rather nice - yes I'm back in the IDE I admit. Short of
    having a keyboard and data logger I dont see how Try Catch is any more
    advantageous in this scenario.

    > If you want to handle a specific error, you can do that more easily
    > with Try Catch Fail than On Error Goto.


    Well the specific errors I normally want to catch I can do quite
    easily with On Error. BUT I do conceed if there is something unique I
    wish to catch then I do genuinely believe Try Catch is better because
    its in line with the rest of the code and I know that this is an
    issue. If its a general error I prefer the On Error approach.

    Of course that does not mean when I will use Error handling in .NET
    that I'll mix the methods.

    Eddie


  4. #19
    Jason Guest

    Re: 'On Error Goto' versus 'Try, Catch, Fail'


    "Eddie Burdak" <eburdak@pilatus-aircraft.com> wrote:
    >Tim,
    >
    >Tim Overbay wrote:
    >> Bull! The easiest way to lose your train of thought while reading
    >> code is by using a goto statement, period.

    >
    >Well I find theeasiest way to lose train of thought is by handling the
    >errors instead of concentrating on what the code is suppose to do. But
    >I guess thats just me.


    I just want to point out that most code does not require any in-line error
    handling at all. In the few cases where you need it, you really SHOULD put
    it where you are dealing with the error, around one or just a few lines of
    code, dealing only with the specific errors you know can occur.

    If the program crashes, it is because of an error you didn't anticipate,
    right? So you find those sorts of things in testing and you fix them. After
    a few days of testing and fixing, all these sorts of crashes take care of
    themselves.

    VB-classic's biggest error-handling problem, in my opinion, is that if you
    want to determine the source of an error in a production app, you have to
    rig every routine with an error trap. This is in addition to any other,
    more specific error handling you need to do.

    The second biggest problem in VB-classic, in my opinion, is that it encourages
    writing error traps for the whole routine, rather than just for specific
    lines. This sort of thing is very hard to get right, since the same error
    can happen on multiple lines, but what you do about it may be entirely wrong
    in one instance or another.

    If you are writing localized error handling routines, Try Catch Finally is
    much cleaner than On Error Goto.

    BUT, if you are willing to write some custom code (including a PUSH and POP
    stack for the Err object), you can - painfully - accomplish anything with
    On Error Goto that you can with Try Catch Finally.

  5. #20
    Mike Mitchell Guest

    Re: 'On Error Goto' versus 'Try, Catch, Fail'

    On 10 Sep 2002 23:35:40 -0700, "Jason" <jason@hotmail.com> wrote:

    >I just want to point out that most code does not require any in-line error
    >handling at all. In the few cases where you need it, you really SHOULD put
    >it where you are dealing with the error, around one or just a few lines of
    >code, dealing only with the specific errors you know can occur.


    And what about the unspecific errors you don't know can occur?

    >If the program crashes, it is because of an error you didn't anticipate,
    >right? So you find those sorts of things in testing and you fix them. After
    >a few days of testing and fixing, all these sorts of crashes take care of
    >themselves.


    Yes, it's because of errors that weren't anticipated. I see error
    handling as a final barrier, the concrete block at the end of the
    track after the signals failed, the points (switches) jammed, the
    driver (engineer) dropped dead, and the automatic braking system
    (brakes) lost all its hoses. During testing I find all sorts of bugs
    and fix them. They don't need error handling. But an ever-present
    concrete block gives me (and my users, though they don't know it's
    made of concrete - they just appreciate bomb-proof apps) a kind of
    warm feeling.

    >VB-classic's biggest error-handling problem, in my opinion, is that if you
    >want to determine the source of an error in a production app, you have to
    >rig every routine with an error trap. This is in addition to any other,
    >more specific error handling you need to do.


    Why is rigging every routine a problem, let alone "VB-classic's
    biggest error-handling problem"? I see the "biggest" error-handling
    problem in classic VB as the lack of a global error handler. But that
    said, On Error GoTo works fine as it is. I just did a quick summary of
    one of my apps and it contains 427 subs or functions. Each and every
    one has an On Error GoTo at the start and a standard error trap at the
    end. Of course, I used an add-in to do this, and why not? VB gives us
    the opportunity to enhance the IDE, so why not take advantage? Yes, if
    I were writing apps and had to manually code On Error GoTo everywhere,
    that would be a real pain. But instead I get VB to fix its own ****.

    >The second biggest problem in VB-classic, in my opinion, is that it encourages
    >writing error traps for the whole routine, rather than just for specific
    >lines. This sort of thing is very hard to get right, since the same error
    >can happen on multiple lines, but what you do about it may be entirely wrong
    >in one instance or another.


    Instance? What's an instance? I only have exactly one original! Okay,
    so I'll admit to creating instances of forms every now and again,
    notably the one to display errors in the unlikely event that one
    should have crept through my brillant coding! But that's because it
    would theoretically be possible to have multiple, cascading errors,
    and therefore multiple instances in that specific case seemed like a
    good idea.

    >If you are writing localized error handling routines, Try Catch Finally is
    >much cleaner than On Error Goto.


    Fair enough. I don't agree, though.

    >BUT, if you are willing to write some custom code (including a PUSH and POP
    >stack for the Err object), you can - painfully - accomplish anything with
    >On Error Goto that you can with Try Catch Finally.


    'Zactly! You can accomplish it with On Error GoTo. And you take away
    the pain by wiring the IDE with a well-targeted add-in or two.

    MM

  6. #21
    Eddie Burdak Guest

    Re: 'On Error Goto' versus 'Try, Catch, Fail'

    Jason,

    Jason wrote:
    > I just want to point out that most code does not require any in-line
    > error handling at all. In the few cases where you need it, you
    > really SHOULD put it where you are dealing with the error, around

    one
    > or just a few lines of code, dealing only with the specific errors
    > you know can occur.


    Yup most code does not. Where I find it rather useful though is at
    data entry in case the file structure required is not observed and
    help the user pinpoint quickly where the problem is in the input file.
    This Input routine is the one that contains most of my error control.
    But it still does not prevent errors occuring downstream.

    > If the program crashes, it is because of an error you didn't
    > anticipate, right? So you find those sorts of things in testing and
    > you fix them. After a few days of testing and fixing, all these
    > sorts of crashes take care of themselves.


    The test phase is with my input - invariably I find the user wants to
    run a simple case and has tried to by pass some of the input. I have
    tried to accomodate this simplier run as it is quite valuable as a
    quick look. but it does open up quite a few possibilites in the code
    for an error to occur.

    > VB-classic's biggest error-handling problem, in my opinion, is that
    > if you want to determine the source of an error in a production app,
    > you have to rig every routine with an error trap. This is in
    > addition to any other, more specific error handling you need to do.


    Yes the routines I want rigigning for error control are all have self
    contained error control - I dont normally want the error going back up
    the stack and being trapped there instead. I dnot actually see this as
    an issue because Try Catch Fail by definition must be in that
    routine - so I assume you mustr be referring to the message the user
    gets when a .NET app fails. But does that help the user?

    > The second biggest problem in VB-classic, in my opinion, is that it
    > encourages writing error traps for the whole routine, rather than
    > just for specific lines. This sort of thing is very hard to get
    > right, since the same error can happen on multiple lines, but what
    > you do about it may be entirely wrong in one instance or another.


    Agreed. It was not very friendly in writing an error trap for a whole
    routine and then you try to catch a specific error.

    > If you are writing localized error handling routines, Try Catch
    > Finally is much cleaner than On Error Goto.


    Well its a path I will be trying - but my gut instinct says its not
    quite as clean (in terms of following the code in the non error mode)

    > BUT, if you are willing to write some custom code (including a PUSH
    > and POP stack for the Err object), you can - painfully - accomplish
    > anything with On Error Goto that you can with Try Catch Finally.


    I must admit I've never explored that path.

    Eddie


  7. #22
    Eddie Burdak Guest

    Re: 'On Error Goto' versus 'Try, Catch, Fail'

    Mike,

    Mike Mitchell wrote:
    > On 10 Sep 2002 23:35:40 -0700, "Jason" <jason@hotmail.com> wrote:


    <Snip>
    >> The second biggest problem in VB-classic, in my opinion, is that it
    >> encourages writing error traps for the whole routine, rather than
    >> just for specific lines. This sort of thing is very hard to get
    >> right, since the same error can happen on multiple lines, but what
    >> you do about it may be entirely wrong in one instance or another.

    >
    > Instance? What's an instance? I only have exactly one original!

    Okay,
    > so I'll admit to creating instances of forms every now and again,
    > notably the one to display errors in the unlikely event that one
    > should have crept through my brillant coding! But that's because it
    > would theoretically be possible to have multiple, cascading errors,
    > and therefore multiple instances in that specific case seemed like a
    > good idea.


    The way I read Jasons para was if there was an oppurtunity for, say, a
    zero divide in more then one location. Maybe in one place its not an
    issue but in another you want to pop of a dialog/input box. In this
    case labels start appearing on a more regular basis in the error traps
    and you get more jumping about. For a pure in line guy he mya have
    issues with that (I'm not saying Jason is a pure in line dude). But
    quite frankely I dont have an issue with it do it right and the labels
    are self commentating in the code.

    Eddie


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