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

"Anthony England" <aengland@xxxxxxxxxx> wrote in
news:dpe8kt$cag$1@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:

> (sorry for the likely repost, but it is still not showing on my
> news server and after that much typing, I don't want to lose it)
>
>
> I am considering general error handling routines and have written
> a sample function to look up an ID in a table. The function
> returns True if it can find the ID and create a recordset based on
> that ID, otherwise it returns false.
>
> **I am not looking for comments on the usefulness of this function
> - it is only to demonstrate error handling**
>
> There are three versions of this code. David Fenton says under
> the earlier thread "DAO peculiarity in A97?" that version 1 is bad
> since it has multiple lines covered by On Error Resume Next and
> that a danger exists of this 'spilling over' into another block of
> code. Can anyone demonstrate this?

Even *I* can't demonstrate it.

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.

Using it shows that you *know* an error is going to happen. To me,
that shows that, instead of saying "ignore the error" you should
trap for it and respond accordingly.

The main reason for this is that you can't anticipate every possible
error, and there could be errors that you *don't* want to ignore
(which is what was happening in the app I cited above).

This is, of course, separate from the issue of scope, which I can't
really prove. All I know is that it appeared to me that On Error
Resume Next was not going out of scope when subroutines ended.

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

Relevant Pages

  • Re: .NET haters ought to get a kick out of this
    ... Bob Butler wrote: ... This statement limits the scope of x to the for block. ... Just as in VB6 - error handling is usually reserved for the highest ... .NET apps are not slow - and least no slow enough to matter for the ...
    (microsoft.public.vb.general.discussion)
  • Re: How long does recordset stay open?
    ... storing preferences is to keep them in a text file and load them from ... You can give it wider scope and a longer lifetime if you declare it in the ... recordset with various default variables used by my program. ...
    (comp.databases.ms-access)
  • Re: no data on a form
    ... Use error handling to ignore than error. ... >> Private Sub OpenMyForm_Click ... > I would, though, implement the error handler as a SELECT CASE, ... The On Error not going out of scope makes sense since the On Error ...
    (comp.databases.ms-access)
  • Re: cleaning up properly
    ... >> I trust the object to clean up after itself when it goes out of scope. ... In the simple example of a routine declaring and then instancing a recordset ... I have had the occasion of working with recordsets that exhibited strange ...
    (microsoft.public.vb.general.discussion)
  • Re: More ASP.Net Newbie Questions
    ... I will grant you that - I found that the error handling and error messages ... Connection and Recordset objects into, like, 37 different things. ... But when you bind data ... to some sort of html control, isn't it pretty much an all-or-nothing deal? ...
    (microsoft.public.dotnet.framework.aspnet)