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


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 2 12 LastLast
Results 1 to 15 of 22

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

  1. #1
    clarence_rollins Guest

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

    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



  2. #2
    Carrot Faced Twerp Guest

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

    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





  3. #3
    Jason Guest

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


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



  4. #4
    Joe \Nuke Me Xemu\ Foster Guest

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

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



  5. #5
    Eddie Burdak Guest

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

    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



  6. #6
    Eddie Burdak Guest

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

    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


  7. #7
    Mike Mitchell Guest

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

    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

  8. #8
    Mike Mitchell Guest

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

    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

  9. #9
    Tim Overbay Guest

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

    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




  10. #10
    Jason Guest

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


    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



  11. #11
    Mike Mitchell Guest

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

    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

  12. #12
    Tim Overbay Guest

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

    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




  13. #13
    Jason Guest

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


    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? ;-)

  14. #14
    Dave Lewis Guest

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

    "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



  15. #15
    Mike Mitchell Guest

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

    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

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