Re: Is David Fenton right about error handling? (re-post?)


"Randy Harris" <randy@xxxxxxxxxxxx> wrote in message
news:XDBuf.45667$7h7.44831@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> "David W. Fenton" <XXXusenet@xxxxxxxxxxxxxxxxxxx> wrote in message
> news:Xns97409DD3B8A3Df99a49ed1d0c49c5bbb2@xxxxxxxxxxxx
>> "Anthony England" <aengland@xxxxxxxxxx> wrote in
>> news:dpe8kt$cag$1@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:
>>
>>
>> However, I had an app that had problems that could only be explained
>> by the use of On Error Resume Next. When those were removed (or
>> allowed to apply to only one line at a time), the problems with data
>> errors being lost disappeared. This was several years ago.
>>
>> Now, philosophically, I have a definite problem with relying on it.
>> It's lazy programming, in my opinion.
>>
>>
>> > Do others have experience of this happening?
>> > It seems he would prefer version 2. But I am wondering - if I
>> > cannot rely on the error handling to be reset when I exit my
>> > function, can I guarantee there is zero possibility of an error in
>> > the Exit_Handler part in version 2? (e.g. the recordset wasn't
>> > nothing, but trying to close it causes an error). If there is an
>> > error in the Exit_Handler part, we obviously get stuck in a
>> > never-ending loop, so to some extent it would make sense to make
>> > sure that this cannot happen. The code is also less verbose,
>> > particularly when there are many objects to be cleared up.
>> > Perhaps the answer is version 3 which tacks on a final 'On Error
>> > GoTo 0' but I have never seen anyone write a function with that
>> > type of error handling.
>>
>> I don't know what errors could happen in closing a recordset. If you
>> are avoiding doing it my way because of a worry about an unforeseen
>> error, then it seems to me to be contradictory of your seeming
>> preference for a method that ignores *all* errors, anticipated or
>> not. In other words, you seem to prefer a method that ignores *all*
>> unforeseen errors to a method that may break if *one* unforeseen
>> error occurs.
>>
>> That seems extremely unwise to me.
>>
>> --
>> David W. Fenton http://www.dfenton.com/
>> usenet at dfenton dot com http://www.dfenton.com/DFA/
>
> I had a problem similar to the one David describes with On Error Resume
> Next. It was particularly bad because I let it get out to a customer that
> way (shame on me). It caused some highly intermittent problems that were
> extremely difficult to pin down. It was several years ago and I no longer
> have the code.
>
> I also agree that its use is "lazy programming" but I still use it on
> occasion. Properly trapping errors is always better, but I'm a lazy
> programmer. The solution that I've come up with is to never, ever leave a
> section of code with On Error Resume Next "unterminated". I consider On
> Error Goto 0 (or Goto something else) a proper termination. I used to put
> Err.Clear ahead of the Goto, but that didn't seem to make any difference.
> Also, keep blocks of code with Resume Next as small as possible and be
> very
> certain that code that doesn't get run and doesn't generate an error can't
> cause problems elsewhere. This "solution" has worked well for me.
>
> --
> Randy Harris
> tech at promail dot com
> I'm pretty sure I know everything that I can remember.


Hi Randy. Thanks for the response. Your mention of Err.Clear prompted me
to re-read the help file which clearly states that the method is called
after the Exit Function. But I guess if you couldn't rely on one, then you
couldn't rely on the other.

' ==================================================
' ====== Acc XP Help File ===============================
Clear Method

Clears all property settings of the Err object.

Syntax

object.Clear

The object is always the Err object.

Remarks

Use Clear to explicitly clear the Err object after an error has been
handled, for example, when you use deferred error handling with On Error
Resume Next. The Clear method is called automatically whenever any of the
following statements is executed:

Any type of Resume statement


Exit Sub, Exit Function, Exit Property


Any On Error statement
Note The On Error Resume Next construct may be preferable to On Error GoTo
when handling errors generated during access to other objects. Checking Err
after each interaction with an object removes ambiguity about which object
was accessed by the code. You can be sure which object placed the error code
in Err.Number, as well as which object originally generated the error (the
object specified in Err.Source).


.

Relevant Pages

  • Re: how do people feel about exit function from loop
    ... How do people feel about using exit function from inside of a loop? ... or exit function is considered bad because it is likened to Goto. ...
    (microsoft.public.vb.general.discussion)
  • Re: On Local Error Goto Somewhere
    ... an EXIT DO or EXIT FOR. ... going if there is no label to show you the destination. ... IMO the GoTo statement has never been "THE" problem. ... ON ERROR GOTO MySubErr Dim lFNbr as long ...
    (microsoft.public.vb.general.discussion)
  • Re: COBOL aint quite dead - yet !
    ... The point about goto is that there is nothing at all wrong with a goto ... For example the use of an exit paragraph signals ... loops - which was all about replacing a GOTO with something that did the ...
    (comp.lang.cobol)
  • [patch 06/10] Introduce path_put()
    ... goto fail; ... return err; ... * Given a path decrement the reference count to the dentry and the vfsmount. ...
    (Linux-Kernel)
  • Re: Is David Fenton right about error handling?
    ... > If Not rst Is Nothing Then ... > Exit Function ... annoying loop) and I can find out what is happening and I will become ...
    (comp.databases.ms-access)