Printable View
I'm not sure how 'Try, Catch, Fail' differs from the following 'On Error Goto' approach:
Sub MyProcedure()
<declare variables>
On Error GoTo PROC_ERROR:
<main code block>
PROC_EXIT:
<cleanup code>
Exit Sub
PROC_ERROR:
Select Case Err.Number
Case <first error case>
Case <next error case>
Case Else
Call LogError(Err, "MyProcedure")
End Select
GoTo PROC_EXIT:
End Sub
In practise, you'd get similar results with both of them.
To my mind though, the Try/Catch system gives the following additional
benefits:
1) A "FileNotFound" exception, to me, is a lot friendlier than an Err.Number
of 76, or whatever it is.
2) The On Error way includes a lot of jumping about, making it hard to
follow the flow.
3) The error handling is with the code that could cause the errors. Some see
this as good, some bad, though.
4) What does the On Error code start to look like with 2, 3, or more sets of
different error handlers in the one Sub? Not pretty, and insanely messy!!
5) An error occurs in your error handler, ironically. With Try/Catch, the
Finally block still gets executed as expected. God only knows what happens
with On Error, or do you add another error handler in there?
6) On Error leaves you checking up in your code to see what the last
declared error handler was, was it Goto PROC_ERROR, or
PROC_ERROR_FOR_FILEOPEN? Best check...
7) Assuming there's a whole group of errors which are only subtely
different, but you have to expose them as seperate errors for other areas of
code that need to tell them apart. E.g. different problems opening a file.
On Error gives you a Select Case of "Case 41-45, 47, 49". With Try/Catch you
could set up the individual File opening execeptions as inheriting from a
master "FileOpenException" class. This way you have the option of checking
for a specific error, or the indivudual ones, in a more organised and
logocal way.
Other than that, I think the On Error code just tends to be messy and
confusing.
If it wasn't for "On Error Resume Next", I'd never use those horrid words
again. If they get a decent way to do that (sometimes it's very handy!), I'd
be a happy man (in an error-handling kind of way).
"clarence_rollins" <clarence_rollins@hotmail.com> wrote in message
news:3d7ae134$1@10.1.10.29...
I'm not sure how 'Try, Catch, Fail' differs from the following 'On Error
Goto' approach:
Sub MyProcedure()
<declare variables>
On Error GoTo PROC_ERROR:
<main code block>
PROC_EXIT:
<cleanup code>
Exit Sub
PROC_ERROR:
Select Case Err.Number
Case <first error case>
Case <next error case>
Case Else
Call LogError(Err, "MyProcedure")
End Select
GoTo PROC_EXIT:
End Sub
Let me expand on what Carrot Face said.
First, when you have an error and jump to an error handler using On Error
Goto, any error in the error handler immediately terminates the function
and raises the error in the function that called it. Messy. And if VB7
is like VB6, there is no way to correct this behavior.
Basically, "On Error Goto..." is the last bastion of the Goto statement.
There are reasons why you should ALMOST never use Goto statements in regular
code. They tend to hork up the program flow and make logic and flow very
difficult.
The same thing happens with On Error Goto versus Try Catch Finally. Yes,
you can do lots of things with iterators and goto statements, but is this
good programming? No, it's messy.
Likewise, programming anything but the simplest error handlers is messy using
On Error Goto statements. If you REALLY, REALLY know what you are doing,
you can accomplish everything with On Error Goto that you can with Try Catch
Finally, but I know a lot of very good VB programmers, and I would be if
even one of them could explain to me all the little idiosyncracies of On
Error Goto. It's a real mess.
Sooo, in conclusion, just use Try Catch Finally instead of On Error Goto.
Pretend that it does not exist. In fact, VB7 would have been better off
without it, but I'm sure Microsoft put it in to allow old-school VB programmers
to feel more comfortable. But it's a throwback to programming more than
a decade ago, and you should just not do it at all.
Try Catch Finally has all the capabilities of On Error Goto, but they are
much easier to use correctly and understand. You are much less likely to
make stupid mistakes in error handling using Try Catch Finally, and you will
spend a lot less time trying to figure out how to do things.
With that said, error handling is an art form, and most people don't really
understand it well. Take some time to read up on error handling in Java
or even VB.NET if you can find some good literature. Understanding the concepts
of when and how to use error handling correctly can make your code 10 times
more robust overnight.
Good luck!
"clarence_rollins" <clarence_rollins@hotmail.com> wrote:
>
>
>I'm not sure how 'Try, Catch, Fail' differs from the following 'On Error
=
>Goto' approach:
>=20
>Sub MyProcedure()
>=20
><declare variables>
>=20
>On Error GoTo PROC_ERROR:
>=20
><main code block>
>=20
>PROC_EXIT:
><cleanup code>
>Exit Sub
>
>PROC_ERROR:
>Select Case Err.Number
>=20
> Case <first error case>
> =20
> Case <next error case>
>=20
> Case Else
> Call LogError(Err, "MyProcedure")
>=20
>End Select
>=20
>GoTo PROC_EXIT:
>=20
>End Sub
> =20
>
>
><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
><HTML><HEAD>
><META http-equiv=3DContent-Type content=3D"text/html; =
>charset=3Diso-8859-1">
><META content=3D"MSHTML 6.00.2715.400" name=3DGENERATOR>
><STYLE></STYLE>
></HEAD>
><BODY>
><DIV><FONT face=3DArial size=3D2>I'm not sure how 'Try, Catch, Fail' =
>differs from=20
>the following*'On Error Goto' approach:<BR>*<BR><FONT =
>face=3DCourier>Sub=20
>MyProcedure()<BR>*<BR><STRONG><EM><declare=20
>variables><BR></EM></STRONG>*<BR>On Error GoTo=20
>PROC_ERROR:<BR>*<BR><EM><STRONG><main code=20
>block><BR></STRONG></EM>*<BR>PROC_EXIT:<BR><STRONG><EM><cleanu=
>p=20
>code><BR></EM></STRONG>Exit Sub</FONT></FONT></DIV>
><DIV><FONT face=3DCourier size=3D2></FONT>*</DIV>
><DIV><FONT face=3DArial size=3D2><FONT =
>face=3DCourier>PROC_ERROR:<BR>Select Case=20
>Err.Number<BR>*<BR>* Case <STRONG><EM><first error=20
>case></EM></STRONG><BR>* <BR>* Case <EM><STRONG><next =
>error=20
>case><BR></STRONG></EM>*<BR>* Case Else<BR>* Call=20
>LogError(Err, "MyProcedure")<BR>*<BR>End Select<BR>*<BR>GoTo=20
>PROC_EXIT:<BR>*<BR>End Sub<BR></FONT>***=20
></FONT></DIV></BODY></HTML>
>
>
"Carrot Faced Twerp" <jesus@heaven.com> wrote in message <news:3d7b4ea1@10.1.10.29>...
> In practise, you'd get similar results with both of them.
> To my mind though, the Try/Catch system gives the following additional
> benefits:
>
> 1) A "FileNotFound" exception, to me, is a lot friendlier than an Err.Number
> of 76, or whatever it is.
Have you ever heard of this obscure keyword named "Const"?
> 2) The On Error way includes a lot of jumping about, making it hard to
> follow the flow.
Perhaps the Sub, Function, or whatever is too big to begin
with and is crying out to be refactored...?
> 3) The error handling is with the code that could cause the errors. Some see
> this as good, some bad, though.
Is there truly no escape from C's extern int errno?
> 4) What does the On Error code start to look like with 2, 3, or more sets of
> different error handlers in the one Sub? Not pretty, and insanely messy!!
Resume 2
> 5) An error occurs in your error handler, ironically. With Try/Catch, the
> Finally block still gets executed as expected. God only knows what happens
> with On Error, or do you add another error handler in there?
Copy the error information and Resume to a cleanup-and-bailout
section, which may or may not then re-Raise the original error,
your choice? Also Google for "On Error GoTo -1"
> 6) On Error leaves you checking up in your code to see what the last
> declared error handler was, was it Goto PROC_ERROR, or
> PROC_ERROR_FOR_FILEOPEN? Best check...
Resume 2
> 7) Assuming there's a whole group of errors which are only subtely
> different, but you have to expose them as seperate errors for other areas of
> code that need to tell them apart. E.g. different problems opening a file.
> On Error gives you a Select Case of "Case 41-45, 47, 49". With Try/Catch you
> could set up the individual File opening execeptions as inheriting from a
> master "FileOpenException" class. This way you have the option of checking
> for a specific error, or the indivudual ones, in a more organised and
> logocal way.
Resume 1
> Other than that, I think the On Error code just tends to be messy and
> confusing.
>
> If it wasn't for "On Error Resume Next", I'd never use those horrid words
> again. If they get a decent way to do that (sometimes it's very handy!), I'd
> be a happy man (in an error-handling kind of way).
If you want to use VBScript, use VBScript. Otherwise, why don't you
try actually learning the language you're attempting to program in?
--
Joe Foster <mailto:jlfoster%40znet.com> L. Ron Dullard <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!
Clarence
clarence_rollins wrote:
> I'm not sure how 'Try, Catch, Fail' differs from the following 'On
> Error Goto' approach:
The difference for me (and I'm sure its to do with the way I
understand things and code) is that On Error Goto generally branches
to some code at the END of the routine desperatly trying to deal with
the error. The error could be caused by a mulititude of things if you
use the statement at the begining of the routine with no On Error in
between other than on On Error GoTo 0 prior to exiting the routine.
Yes it braches somewhere - but dealing a lot with FORTRAN code I dont
have the same issues the in line guys do. Its an exception - but the
error is an exception as well.
The Try Catch Fail appears to me to be much more in line. Try the
following code and if it works do this block and ignore the next, if
it fails execute the following block - not the block at the end of the
routine. So error handling appears more in line.
I don't think the Try Catch Fail allows you to trap more errors. On
Error GoTo will catch them too - its just the code for dealing with
the errors is always at the end of the module the old way.
Actually I quite liked it because the base code is tight and neat
dealing with only a working system - all the error handling is at the
end out of the way. Try Catch Fail blows up the code in the middle -
but it does have the advatage that you keep reading there to see how
it deals with the error and not at the end where it may be dealing
with more than one type of failure.
Or am I off base?
Eddie
Dude,
I forgot to mention that (again maybe its just my sceptical nature)
but maybe MS have allowed On Erroor GoTo in .NET v 1 but are warning
you that they will be droping it in the future for Try Catch Fail.
After all I suspect you couldn't convert that Error handling code in
the migration wizard.
VB.NET I though would clean up the language and allow you to do things
but only one way to get rid of archic code. This I think is an example
of where MS had a perfect oppurtunity to deal with it but decided
against it for one reason or another.
Eddie
On 8 Sep 2002 12:31:47 -0700, "Jason" <jason@hotmail.com> wrote:
>Likewise, programming anything but the simplest error handlers is messy using
>On Error Goto statements. If you REALLY, REALLY know what you are doing,
>you can accomplish everything with On Error Goto that you can with Try Catch
>Finally, but I know a lot of very good VB programmers, and I would be if
>even one of them could explain to me all the little idiosyncracies of On
>Error Goto. It's a real mess.
No, it's not a real mess. I have been using On Error GoTo and On Error
Resume Next for years, and rarely have they caused any problem. What
they have done is provide me with bomb-proof applications with minimum
fuss. If your error handling code is "a real mess" I would suggest
that the code itself is also a real mess, since enough preemptive
coding should have been done long before execution gets that far
anyway. My motto is to put an On Error GoTo error trap in EVERY
routine. I even wrote add-ins to help manipulate projects to
streamline the provision of error trapping.
As you said, you can accomplish everything with On Error GoTo, and
that's good enough for me!
MM
On Mon, 9 Sep 2002 09:58:12 +0200, "Eddie Burdak"
<eburdak@pilatus-aircraft.com> wrote:
>Actually I quite liked it because the base code is tight and neat
>dealing with only a working system - all the error handling is at the
>end out of the way.
'Zactly! When I'm reading code, I don't want to keep being brought up
with a jolt to read error handling code that has nothing to do with
the logic of the actual subroutine. The code, especially well-written
B.A.S.I.C. code, should not need to be arcane (unlike, say, C++, with
which that failing's inevitable), and should read almost like a book,
with proper English words mostly written out in full to aid
comprehension. That is, we don't perceive the words, we just read them
as we would when reading a book or a newspaper, and are continually
translating their meaning into the logic they represent. Then, BOOM!
Error handling code right smack in the middle of your train of
thought! Doesn't make any sense to me to do it that way at all.
Admittedly, this is unavoidable when the construct On Error Resume
Next is used, but I only make minimal use of that anyway.
> Try Catch Fail blows up the code in the middle -
>but it does have the advatage that you keep reading there to see how
>it deals with the error and not at the end where it may be dealing
>with more than one type of failure.
>
>Or am I off base?
No, you're not!
MM
Bull! The easiest way to lose your train of thought while reading code is by
using a goto statement, period. Proper error handling *is* part of the logic
of the program and *should* be placed where inline where it's appropriate,
not tacked on to the end of each sub or function.
You poor .NOT schloobs are really starting to reach now!
Tim
"Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
news:1l0pnucp9f0np6no873t8bb4fok2n92uaa@4ax.com...
> On Mon, 9 Sep 2002 09:58:12 +0200, "Eddie Burdak"
> <eburdak@pilatus-aircraft.com> wrote:
>
> >Actually I quite liked it because the base code is tight and neat
> >dealing with only a working system - all the error handling is at the
> >end out of the way.
>
> 'Zactly! When I'm reading code, I don't want to keep being brought up
> with a jolt to read error handling code that has nothing to do with
> the logic of the actual subroutine. The code, especially well-written
> B.A.S.I.C. code, should not need to be arcane (unlike, say, C++, with
> which that failing's inevitable), and should read almost like a book,
> with proper English words mostly written out in full to aid
> comprehension. That is, we don't perceive the words, we just read them
> as we would when reading a book or a newspaper, and are continually
> translating their meaning into the logic they represent. Then, BOOM!
> Error handling code right smack in the middle of your train of
> thought! Doesn't make any sense to me to do it that way at all.
> Admittedly, this is unavoidable when the construct On Error Resume
> Next is used, but I only make minimal use of that anyway.
>
> > Try Catch Fail blows up the code in the middle -
> >but it does have the advatage that you keep reading there to see how
> >it deals with the error and not at the end where it may be dealing
> >with more than one type of failure.
> >
> >Or am I off base?
>
> No, you're not!
>
> MM
No, Mike, actually Tim is correct on this one. You would be the one guy on
the whole planet who prefers On Error Goto to Try Catch, but then, you don't
do a whole lot of error handling.
Almost without exception, the WRONG thing to do is to use a single error
handler to handle all errors in your function. Yet that is what the majority
of VB programmers tend to do, and it is how they tend to think. Why? Because
On Error Goto made this type of error handling easy, and made the good type
hard.
I have written a couple of papers that explained error handling in VB-classic
several years back. I know it very well. I could point out all kinds of
problems with it, but I don't really have the time or the motivation right
here and now. Let's just say that it has some major problems, okay?
For everyone reading this, please stick with Try Catch Finally and avoid
On Error Goto and On Error Resume Next. If you find Try Catch Finally to
be awkward, but find On Error Goto to be easy, you probably are approaching
error handling from the wrong angle. Sit back, think about it, and try again.
:-)
Mike Mitchell <kylix_is@yahoo.co.uk> wrote:
>On Mon, 9 Sep 2002 08:30:56 -0600, "Tim Overbay"
><luhar@neverendingsoftware.com> wrote:
>
>>Bull! The easiest way to lose your train of thought while reading code
is by
>>using a goto statement, period. Proper error handling *is* part of the
logic
>>of the program and *should* be placed where inline where it's appropriate,
>>not tacked on to the end of each sub or function.
>
>On Error GoTo is placed at the start of the routine! And the trap is
>at the end. Both are well out of the way of normal reading flow.
>
>I see error handling like the fire blanket you have next to you in the
>kitchen (you *do* have one, don't you?). It's for safety,
>"just...in...case..." That's how I see error handling. You really
>should not need it if you have taken the correct preemptive coding
>measures first, but in case there are events outside your control, the
>error handling code will deal with it. It's worked for me for years,
>so I Have The Proof !
>
>MM
On Mon, 9 Sep 2002 08:30:56 -0600, "Tim Overbay"
<luhar@neverendingsoftware.com> wrote:
>Bull! The easiest way to lose your train of thought while reading code is by
>using a goto statement, period. Proper error handling *is* part of the logic
>of the program and *should* be placed where inline where it's appropriate,
>not tacked on to the end of each sub or function.
On Error GoTo is placed at the start of the routine! And the trap is
at the end. Both are well out of the way of normal reading flow.
I see error handling like the fire blanket you have next to you in the
kitchen (you *do* have one, don't you?). It's for safety,
"just...in...case..." That's how I see error handling. You really
should not need it if you have taken the correct preemptive coding
measures first, but in case there are events outside your control, the
error handling code will deal with it. It's worked for me for years,
so I Have The Proof !
MM
At least we agree on that point. Error-handling code is for exceptions to
the normal behavior of the program or, more commonly, the user. If I'm
reading code (especially somebody else's) I want to know if/when/where it's
handling exceptions. "On Error Goto" just convolutes that, imo.
Nevertheless, structured vs. non-structured error-handling is really a moot
argument as far as VB.NET's concerned. It allows both methods.
'nuff said.
Tim
"Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
news:fsqpnuogdrgc1fkgqqqh41kv4s7kck11v2@4ax.com...
> On Mon, 9 Sep 2002 08:30:56 -0600, "Tim Overbay"
> <luhar@neverendingsoftware.com> wrote:
>
> >Bull! The easiest way to lose your train of thought while reading code is
by
> >using a goto statement, period. Proper error handling *is* part of the
logic
> >of the program and *should* be placed where inline where it's
appropriate,
> >not tacked on to the end of each sub or function.
>
> On Error GoTo is placed at the start of the routine! And the trap is
> at the end. Both are well out of the way of normal reading flow.
>
> I see error handling like the fire blanket you have next to you in the
> kitchen (you *do* have one, don't you?). It's for safety,
> "just...in...case..." That's how I see error handling. You really
> should not need it if you have taken the correct preemptive coding
> measures first, but in case there are events outside your control, the
> error handling code will deal with it. It's worked for me for years,
> so I Have The Proof !
>
> MM
Mike Mitchell <kylix_is@yahoo.co.uk> wrote:
>No, it's not a real mess. I have been using On Error GoTo and On Error
>Resume Next for years, and rarely have they caused any problem. What
>they have done is provide me with bomb-proof applications with minimum
>fuss. If your error handling code is "a real mess" I would suggest
>that the code itself is also a real mess, since enough preemptive
>coding should have been done long before execution gets that far
>anyway. My motto is to put an On Error GoTo error trap in EVERY
>routine. I even wrote add-ins to help manipulate projects to
>streamline the provision of error trapping.
>
>As you said, you can accomplish everything with On Error GoTo, and
>that's good enough for me!
>
>MM
Mike, you have to make up your mind. You want VB to be this scripting language
that anyone can use, yet you advocate putting error traps in every function.
You even say you have written add-ins to help with this.
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.
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.
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.
It is simply inexcusable that VB6 does not provide a way outside the IDE
to determine where a program crashed. But if you want that, you have to
roll your own solution, and doing it right is not easy.
If you want to handle a specific error, you can do that more easily with
Try Catch Fail than On Error Goto.
Want to debate on any more of the fine points of error handling in VB-classic,
and why it is inadequate? ;-)
"Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
news:fsqpnuogdrgc1fkgqqqh41kv4s7kck11v2@4ax.com...
> On Mon, 9 Sep 2002 08:30:56 -0600, "Tim Overbay"
> <luhar@neverendingsoftware.com> wrote:
>
> >Bull! The easiest way to lose your train of thought while reading code is
by
> >using a goto statement, period. Proper error handling *is* part of the
logic
> >of the program and *should* be placed where inline where it's
appropriate,
> >not tacked on to the end of each sub or function.
>
> On Error GoTo is placed at the start of the routine! And the trap is
> at the end. Both are well out of the way of normal reading flow.
>
> I see error handling like the fire blanket you have next to you in the
> kitchen (you *do* have one, don't you?). It's for safety,
> "just...in...case..." That's how I see error handling. You really
> should not need it if you have taken the correct preemptive coding
> measures first, but in case there are events outside your control, the
> error handling code will deal with it. It's worked for me for years,
> so I Have The Proof !
I must admit that I really have to wonder (again) just how much you actually
use your beloved Delphi/Kylix Mike? I mean, the *only* error handling
mechanism in Delphi/Kylix is the "Try..Catch..Finally" method. Either that
or my Enterprise 4 & Enterprise 6 versions are really badly broken. So if
you despise the "Try..Catch..Finally" method of exception handling so much,
how on earth can you stand to use Delphi/Kylix?
--
DHL
Never ascribe to malice, that which can be explained by incompetence
On Mon, 9 Sep 2002 22:01:24 +0100, "Dave Lewis"
<zenadsl2455@zen.co.uk> wrote:
> So if
>you despise the "Try..Catch..Finally" method of exception handling so much,
>how on earth can you stand to use Delphi/Kylix?
I hold my nose when I get to that bit! Don't forget that I'm looking
at Delphi/Kylix as alternatives to VB.Net, on the basis that *if* I'm
going to go to the bother of learning a new product, I'd prefer to
spend the time and effort doing it with a non-Microsoft product.
But I'd still *rather* be using classic VB, if it had a life left to
live instead of nothing but the buffers to look forward to. Talk about
termination with extreme prejudice! I'm surprised they didn't pop
round to Alan Cooper's place and stick a horse's head in the bed.
MM
