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

[Mike Mitchell]

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

[Eddie Burdak]

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

[Eddie Burdak]

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

[Jason]

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

[Mike Mitchell]

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

[Eddie Burdak]

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

[Eddie Burdak]

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