Is David Fenton right about error handling?

[Anthony England]

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?
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 am undecided and seeking the group's opinions**

Public Function ContactExists1(lngConID As Long) As Boolean

On Error GoTo Err_Handler

Dim dbs As DAO.Database
Dim rst As DAO.Recordset
Dim strSQL As String

strSQL = "SELECT tblContact.* FROM tblContact WHERE " & _
"ConID=" & CStr(lngConID)

Set dbs = CurrentDb

Set rst = dbs.OpenRecordset(strSQL, dbOpenForwardOnly, dbReadOnly)

If Not rst.EOF Then
ContactExists1 = True
End If

Exit_Handler:
On Error Resume Next
rst.Close
Set rst = Nothing
Set dbs = Nothing
Exit Function

Err_Handler:
MsgBox Err.Description, vbExclamation, "Error No: " & Err.Number
Resume Exit_Handler

End Function

Public Function ContactExists2(lngConID As Long) As Boolean

On Error GoTo Err_Handler

Dim dbs As DAO.Database
Dim rst As DAO.Recordset
Dim strSQL As String

strSQL = "SELECT tblContact.* FROM tblContact WHERE " & _
"ConID=" & CStr(lngConID)

Set dbs = CurrentDb

Set rst = dbs.OpenRecordset(strSQL, dbOpenForwardOnly, dbReadOnly)

If Not rst.EOF Then
ContactExists2 = True
End If

Exit_Handler:

If Not rst Is Nothing Then
rst.Close
Set rst = Nothing
End If

If Not dbs Is Nothing Then
Set dbs = Nothing
End If

Exit Function

Err_Handler:
MsgBox Err.Description, vbExclamation, "Error No: " & Err.Number
Resume Exit_Handler

End Function

Public Function ContactExists3(lngConID As Long) As Boolean

On Error GoTo Err_Handler

Dim dbs As DAO.Database
Dim rst As DAO.Recordset
Dim strSQL As String

strSQL = "SELECT tblContact.* FROM tblContact WHERE " & _
"ConID=" & CStr(lngConID)

Set dbs = CurrentDb

Set rst = dbs.OpenRecordset(strSQL, dbOpenForwardOnly, dbReadOnly)

If Not rst.EOF Then
ContactExists3 = True
End If

Exit_Handler:
On Error Resume Next
rst.Close
Set rst = Nothing
Set dbs = Nothing
On Error GoTo 0
Exit Function

Err_Handler:
MsgBox Err.Description, vbExclamation, "Error No: " & Err.Number
Resume Exit_Handler

End Function

[Bri]

Personally, I use the second variation. I guess the key thing is that
your Error handler not create new errors. The line; 'If Not rst Is
Nothing Then' is written so that it should not (tempting to say will not
in this case) error. I think that if there is a way of writing the code
so that you eliminate errors rather than ignore them that that is
preferred. Keep in mind that the purpose of an error handler is to
handle the error (seems so obvious when you word it that way :{) ) so
that the problem is either solved by the handler or reported to the user
so he can report it to you (and then you fix the problem and/or the
error handler to deal with the scenario). Ideally, the user will never
see an error message. Realisticly, the errors will happen, so youneed to
handle them in the most user friendly way you can.

--
Bri

Anthony England wrote:

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?
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 am undecided and seeking the group's opinions**

Public Function ContactExists1(lngConID As Long) As Boolean

On Error GoTo Err_Handler

Dim dbs As DAO.Database
Dim rst As DAO.Recordset
Dim strSQL As String

strSQL = "SELECT tblContact.* FROM tblContact WHERE " & _
"ConID=" & CStr(lngConID)

Set dbs = CurrentDb

Set rst = dbs.OpenRecordset(strSQL, dbOpenForwardOnly, dbReadOnly)

If Not rst.EOF Then
ContactExists1 = True
End If

Exit_Handler:
On Error Resume Next
rst.Close
Set rst = Nothing
Set dbs = Nothing
Exit Function

Err_Handler:
MsgBox Err.Description, vbExclamation, "Error No: " & Err.Number
Resume Exit_Handler

End Function

Public Function ContactExists2(lngConID As Long) As Boolean

On Error GoTo Err_Handler

Dim dbs As DAO.Database
Dim rst As DAO.Recordset
Dim strSQL As String

strSQL = "SELECT tblContact.* FROM tblContact WHERE " & _
"ConID=" & CStr(lngConID)

Set dbs = CurrentDb

Set rst = dbs.OpenRecordset(strSQL, dbOpenForwardOnly, dbReadOnly)

If Not rst.EOF Then
ContactExists2 = True
End If

Exit_Handler:

If Not rst Is Nothing Then
rst.Close
Set rst = Nothing
End If

If Not dbs Is Nothing Then
Set dbs = Nothing
End If

Exit Function

Err_Handler:
MsgBox Err.Description, vbExclamation, "Error No: " & Err.Number
Resume Exit_Handler

End Function

Public Function ContactExists3(lngConID As Long) As Boolean

On Error GoTo Err_Handler

Dim dbs As DAO.Database
Dim rst As DAO.Recordset
Dim strSQL As String

strSQL = "SELECT tblContact.* FROM tblContact WHERE " & _
"ConID=" & CStr(lngConID)

Set dbs = CurrentDb

Set rst = dbs.OpenRecordset(strSQL, dbOpenForwardOnly, dbReadOnly)

If Not rst.EOF Then
ContactExists3 = True
End If

Exit_Handler:
On Error Resume Next
rst.Close
Set rst = Nothing
Set dbs = Nothing
On Error GoTo 0
Exit Function

Err_Handler:
MsgBox Err.Description, vbExclamation, "Error No: " & Err.Number
Resume Exit_Handler

End Function

[Rick Brandt]

Anthony England wrote:

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? Do others have experience of this
happening?

Anecdotal only, but I have hundreds of exit routines that use On Error
Resume next prior to the clean up code and have never seen an issue with
it.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[Chuck Grimsby]

On Tue, 03 Jan 2006 21:33:21 GMT, "Rick Brandt"
<ri*********@hotmail.com> wrote:

Anthony England wrote:

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? Do others have experience of this
happening?

Anecdotal only, but I have hundreds of exit routines that use On Error
Resume next prior to the clean up code and have never seen an issue with
it.

I have the same experience myself, Rick.

"On Error Resume Next" is one of the more powerful commands in the
Access (or more appropriately, VBA) Developers tool box, however
(having said that) I must also say that it's not a cure-all for
whatever errors appear. Checking the error collection(s) is *still* a
must, as is the use of the "On Error GoTo 0" command to turn off the
"On Error Resume Next" command.
--
Drive C: Error. (A)bort (R)etry (S)mack The Darned Thing

[Anthony England]

"Bri" <no*@here.com> wrote in message
news:xuBuf.240308$ki.189172@pd7tw2no...

Personally, I use the second variation. I guess the key thing is that
your Error handler not create new errors. The line; 'If Not rst Is Nothing
Then' is written so that it should not (tempting to say will not in this
case) error. I think that if there is a way of writing the code so that
you eliminate errors rather than ignore them that that is preferred. Keep
in mind that the purpose of an error handler is to handle the error (seems
so obvious when you word it that way :{) ) so that the problem is either
solved by the handler or reported to the user so he can report it to you
(and then you fix the problem and/or the error handler to deal with the
scenario). Ideally, the user will never see an error message. Realisticly,
the errors will happen, so youneed to handle them in the most user
friendly way you can.

--
Bri

OK I know I am cheating, by now choosing to use ADO instead of DAO, but
consider version 4. It is similar to the version 2 which you approve of.
This function works fine as long as tblContact is there, but if I rename the
table to tblBogus for instance, I get stuck in a never-ending loop caused by
me trying to shut the recordset if it is not nothing (should have checked if
it was actually open).
Now I don't know whether there is any way you can have a DAO recordset which
'is not nothing' but either not to be open or to be un-closable due to some
other reason (** can anyone think of an example??? **). However, this is
possible with ADO and I am concerned with the general principal of
guaranteeing that exit code always exits and never-ending loops cannot
occur.
Public Function ContactExists4(lngConID As Long) As Boolean

On Error GoTo Err_Handler

Dim rst As ADODB.Recordset
Dim strSQL As String

strSQL = "SELECT tblContact.* FROM tblContact WHERE " & _
"ConID=" & CStr(lngConID)

Set rst = New ADODB.Recordset

rst.Open strSQL, CurrentProject.Connection

If Not rst.EOF Then
ContactExists4 = True
End If

Exit_Handler:

If Not rst Is Nothing Then
rst.Close
Set rst = Nothing
End If

Exit Function

Err_Handler:
MsgBox Err.Description, vbExclamation, "Error No: " & Err.Number
Resume Exit_Handler

End Function

[Anthony England]

"Bri" <no*@here.com> wrote in message
news:xuBuf.240308$ki.189172@pd7tw2no...

Personally, I use the second variation. I guess the key thing is that
your Error handler not create new errors. The line; 'If Not rst Is Nothing
Then' is written so that it should not (tempting to say will not in this
case) error. I think that if there is a way of writing the code so that
you eliminate errors rather than ignore them that that is preferred. Keep
in mind that the purpose of an error handler is to handle the error (seems
so obvious when you word it that way :{) ) so that the problem is either
solved by the handler or reported to the user so he can report it to you
(and then you fix the problem and/or the error handler to deal with the
scenario). Ideally, the user will never see an error message. Realisticly,
the errors will happen, so youneed to handle them in the most user
friendly way you can.

--
Bri

OK I know I am cheating, by now choosing to use ADO instead of DAO, but
consider version 4. It is similar to the version 2 which you approve of.
This function works fine as long as tblContact is there, but if I rename the
table to tblBogus for instance, I get stuck in a never-ending loop caused by
me trying to shut the recordset if it is not nothing (should have checked if
it was actually open).
Now I don't know whether there is any way you can have a DAO recordset which
'is not nothing' but either not to be open or to be un-closable due to some
other reason (** can anyone think of an example??? **). However, this is
possible with ADO and I am concerned with the general principal of
guaranteeing that exit code always exits and never-ending loops cannot
occur.
Public Function ContactExists4(lngConID As Long) As Boolean

On Error GoTo Err_Handler

Dim rst As ADODB.Recordset
Dim strSQL As String

strSQL = "SELECT tblContact.* FROM tblContact WHERE " & _
"ConID=" & CStr(lngConID)

Set rst = New ADODB.Recordset

rst.Open strSQL, CurrentProject.Connection

If Not rst.EOF Then
ContactExists4 = True
End If

Exit_Handler:

If Not rst Is Nothing Then
rst.Close
Set rst = Nothing
End If

Exit Function

Err_Handler:
MsgBox Err.Description, vbExclamation, "Error No: " & Err.Number
Resume Exit_Handler

End Function

[Darryl Kerkeslager]

"Anthony England" <ae******@oops.co.uk> wrote

Public Function ContactExists4(lngConID As Long) As Boolean
On Error GoTo Err_Handler

Dim rst As ADODB.Recordset
Dim strSQL As String

strSQL = "SELECT tblContact.* FROM tblContact WHERE " & _
"ConID=" & CStr(lngConID)

Set rst = New ADODB.Recordset
rst.Open strSQL, CurrentProject.Connection
If Not rst.EOF Then
ContactExists4 = True
End If
' Exit_Handler:
' If Not rst Is Nothing Then rst.Close ' Set rst = Nothing
' End If
Exit Function

Err_Handler:
MsgBox Err.Description, vbExclamation, "Error No: " & Err.Number ' Resume Exit_Handler
End Function

Let's say that you delete the commented lines ... what's the worst that
could happen? You're recordset is not closed if you exit on error. Big
memory loss? Program crash?

What are the possibilities of it being left in that state?

rst.Open will throw an error if the SQL is wrong - so rst is never opened.

Perhaps it's "sloppy" to leave the possibilty of rst not being closed ...
but what is the worst case?
--
Darryl Kerkeslager

[David W. Fenton]

"Anthony England" <ae******@oops.co.uk> wrote in
news:dp**********@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com:

OK I know I am cheating, by now choosing to use ADO instead of
DAO, but consider version 4.

ADO doesn't have the memory leaks that require cleanup.

That is, you don't *need* to close an ADO recordset and set its
object variable to Nothing -- that will happen automatically when
the code goes out of scope.

So, you've introduced a completely artifical error into the
discussion, one that can be avoided by simply not doing the task
that's producing the error.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

"Darryl Kerkeslager" <ke*********@comcast.net> wrote in
news:4s********************@comcast.com:

"Anthony England" <ae******@oops.co.uk> wrote

Public Function ContactExists4(lngConID As Long) As Boolean
On Error GoTo Err_Handler

Dim rst As ADODB.Recordset
Dim strSQL As String

strSQL = "SELECT tblContact.* FROM tblContact WHERE " & _
"ConID=" & CStr(lngConID)

Set rst = New ADODB.Recordset
rst.Open strSQL, CurrentProject.Connection
If Not rst.EOF Then
ContactExists4 = True
End If

' Exit_Handler:
' If Not rst Is Nothing Then

rst.Close

' Set rst = Nothing
' End If

Exit Function

Err_Handler:
MsgBox Err.Description, vbExclamation, "Error No: " &
Err.Number

' Resume Exit_Handler

End Function

Let's say that you delete the commented lines ... what's the worst
that could happen? You're recordset is not closed if you exit on
error. Big memory loss? Program crash?

What are the possibilities of it being left in that state?

rst.Open will throw an error if the SQL is wrong - so rst is never
opened.

Perhaps it's "sloppy" to leave the possibilty of rst not being
closed ... but what is the worst case?

Since VBA with ADO doesn't have the memory leak that VBA with DAO
has, there's absolutely no reason to include cleanup for ADO.

And if you know that errors in the SQL can error out on opening the
recordset, but still leave it as Not Nothing, then you need to test
for that in your error handler if you intend to do the cleanup.

I'm glad I don't use ADO. This kind of thing is bloody stupid, seems
to me, in that it removes any ability to distinguish a properly
initialized recordset from one that has errored out when it was
opened.

I don't like what I see as a too extremely-class-based approach to
the initialization of these objects.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

"Rick Brandt" <ri*********@hotmail.com> wrote in
news:B4*******************@newssvr14.news.prodigy. com:

Anthony England wrote:

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? Do others have
experience of this happening?

Anecdotal only, but I have hundreds of exit routines that use On
Error Resume next prior to the clean up code and have never seen
an issue with it.

I've never used it in an error handler -- I've only done On Error
Resume exitRoutine.

If I want to ignore an error I use a different label to jump back to
the next line.

It's something I need so seldom that I've never contemplated using
Reume Next in place of a label to jump back to.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Tom van Stiphout]

On Tue, 03 Jan 2006 21:33:21 GMT, "Rick Brandt"
<ri*********@hotmail.com> wrote:

I use On Error Resume Next as well. The only drawback that I can see
is that AFAIK in VBA an error handler is an expensive thing to use,
computation wise. In most routines a few more microseconds is not a
problem. One notable exception is functions that are called from
queries. Those I typically do not have any error handler in. Rather I
reserve my perfect code for those functions :-)

-Tom.

Anthony England wrote:

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? Do others have experience of this
happening?

Anecdotal only, but I have hundreds of exit routines that use On Error
Resume next prior to the clean up code and have never seen an issue with
it.

[Anthony England]

"David W. Fenton" <XX*******@dfenton.com.invalid> wrote in message
news:Xn**********************************@127.0.0. 1...

"Anthony England" <ae******@oops.co.uk> wrote in
news:dp**********@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com:

OK I know I am cheating, by now choosing to use ADO instead of
DAO, but consider version 4.

ADO doesn't have the memory leaks that require cleanup.

That is, you don't *need* to close an ADO recordset and set its
object variable to Nothing -- that will happen automatically when
the code goes out of scope.

So, you've introduced a completely artifical error into the
discussion, one that can be avoided by simply not doing the task
that's producing the error.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

The point under discussion is what happens if an unexpected error occurs in
the ExitFunction part of the code. I cannot give you an example of an error
which I cannot foresee, so I did indeed introduce a predictable,
reproducible error to demonstrate what would happen if rst.Close failed.
If the recordset is DAO, then I do not know if it is ever possible for <If
Not rst Is Nothing Then rst.Close> to fail. What puzzles me is the worry
that On Error Resume Next will 'spill over' the Exit Function line (despite
the documentation saying this will not happen - and nobody being able to
reproduce this) contrasted with the lack of concern that the ExitFunction
coding could ever cause an error.

[Keith Wilby]

"Anthony England" <ae******@oops.co.uk> wrote in message
news:dp**********@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com...

"David W. Fenton" <XX*******@dfenton.com.invalid> wrote in message
news:Xn**********************************@127.0.0. 1...

"Anthony England" <ae******@oops.co.uk> wrote in
news:dp**********@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com:

So, you've introduced a completely artifical error into the
discussion, one that can be avoided by simply not doing the task
that's producing the error.

The point under discussion is what happens if an unexpected error occurs
in the ExitFunction part of the code. I cannot give you an example of an
error which I cannot foresee, so I did indeed introduce a predictable,
reproducible error to demonstrate what would happen if rst.Close failed.

Do my eyes deceive me? Is David Fenton wrong? Thank god I'm in his
killfile so he doesn't lead me up the garden path.

:-)

[Rick Brandt]

David W. Fenton wrote:

I've never used it in an error handler -- I've only done On Error
Resume exitRoutine.

If I want to ignore an error I use a different label to jump back to
the next line.

It's something I need so seldom that I've never contemplated using
Reume Next in place of a label to jump back to.

Just to clarify. I do not use it in error handlers either. I just use it in my
exit routines when I am closing objects that might not have been opened due to
an error that was handled by my error handler.
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[Terry Kreft]

Because you should be doing something like:-

Exit_Handler:

If Not rst Is Nothing Then
if rst.state <> adStateClosed then
rst.Close
end if
Set rst = Nothing
End If

Exit Function

Err_Handler:
MsgBox Err.Description, vbExclamation, "Error No: " & Err.Number
Resume Exit_Handler

End Function

If you're in the clean up phase of your code, as you are in the
Exit_Handler, then you need to ensure your code is solid. Personally I
would code it as follows.

Exit_Handler:
On Error resume Next
If Not rst Is Nothing Then
if rst.state <> adStateClosed then
rst.Close
end if
Set rst = Nothing
End If
On Error GoTo 0
Exit Function

Err_Handler:
MsgBox Err.Description, vbExclamation, "Error No: " & Err.Number
Resume Exit_Handler

End Function

On Error Resume Next can get you into infinite loops though, erm trying to
think of an example, Oh yeah this should do it:-

On Error resume Next
Do While (rst.state and adStateOpen) = adStateOpen
rst.Close
Loop
Set rst = Nothing

--
Terry Kreft

"Anthony England" <ae******@oops.co.uk> wrote in message
news:dp**********@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com...

"Bri" <no*@here.com> wrote in message
news:xuBuf.240308$ki.189172@pd7tw2no...

Personally, I use the second variation. I guess the key thing is that
your Error handler not create new errors. The line; 'If Not rst Is
Nothing Then' is written so that it should not (tempting to say will not
in this case) error. I think that if there is a way of writing the code
so that you eliminate errors rather than ignore them that that is
preferred. Keep in mind that the purpose of an error handler is to handle
the error (seems so obvious when you word it that way :{) ) so that the
problem is either solved by the handler or reported to the user so he can
report it to you (and then you fix the problem and/or the error handler
to deal with the scenario). Ideally, the user will never see an error
message. Realisticly, the errors will happen, so youneed to handle them
in the most user friendly way you can.

--
Bri

OK I know I am cheating, by now choosing to use ADO instead of DAO, but
consider version 4. It is similar to the version 2 which you approve of.
This function works fine as long as tblContact is there, but if I rename
the table to tblBogus for instance, I get stuck in a never-ending loop
caused by me trying to shut the recordset if it is not nothing (should
have checked if it was actually open).
Now I don't know whether there is any way you can have a DAO recordset
which 'is not nothing' but either not to be open or to be un-closable due
to some other reason (** can anyone think of an example??? **). However,
this is possible with ADO and I am concerned with the general principal of
guaranteeing that exit code always exits and never-ending loops cannot
occur.
Public Function ContactExists4(lngConID As Long) As Boolean

On Error GoTo Err_Handler

Dim rst As ADODB.Recordset
Dim strSQL As String

strSQL = "SELECT tblContact.* FROM tblContact WHERE " & _
"ConID=" & CStr(lngConID)

Set rst = New ADODB.Recordset

rst.Open strSQL, CurrentProject.Connection

If Not rst.EOF Then
ContactExists4 = True
End If

Exit_Handler:

If Not rst Is Nothing Then
rst.Close
Set rst = Nothing
End If

Exit Function

Err_Handler:
MsgBox Err.Description, vbExclamation, "Error No: " & Err.Number
Resume Exit_Handler

End Function

[Tim Marshall]

Rick Brandt wrote:

Just to clarify. I do not use it in error handlers either. I just use it in my
exit routines when I am closing objects that might not have been opened due to
an error that was handled by my error handler.

That's my approach too. However consider the following example. And
yes, I'm sure many will consider it lazy programming and I have to admit
it is.

COnsider a command button whose only purpose is open a form. The form
to be opened has a number of checks in its on open event. COnsider an
editing form we *don't* want to open if there is no record selected on
the continuous for or sub form datasheet on the calling form. In the
frmSetUpWeather form below, the on open event checks for a currently
selected record (or indeed if there are any records in the calling
form). If this condition fails, then a msgbox explains the problem and
cancel = True.

This will always generate a 2501 error from the calling procedure and I
handle such as shown in the code below. However, this is a lot to write
(though much of it is simply rote with me), so frequently what I do is
knowing the only real error will be the 2501, I do this:

Private Sub btnEdit_Click()

On Error Resume Next

DoCmd.OpenForm "frmSetUpWeather", acNormal

On Error GoTo 0

End Sub

Yes, I do realize I should hang my head in shame, but the above can be
easier than the last bit of code shown below.

My standard approach to writing any procedure is to bang in On Error
GoTo Err_Proc at the beginning, and a standard handling proc like the
one below, but with just a case else in the select err.number. If the
procedure is going to be complex, I comment out the 'On Error Goto
ErrProc and proceed a little bit at a time. That way I can see errors
immediately and those which should be part of the error handling, as
opposed to just stupidity on my part. Such errors that can be a
legitimate result of the proc are added to the case statements in the
select err.number statement.

Here's what I think is the "proper" way to do things. I specify "I
think", because I go trashed yesterday for stating something I thought
was the case....

Private Sub btnEdit_Click()

On Error GoTo Err_Proc

DoCmd.OpenForm "frmSetUpWeather", acNormal

Exit_Proc:

Exit Sub

Err_Proc:

Select Case Err.Number

Case 2501

'frmWEather cancelled - do nothing, frmWeather
'will have displayed a msgbox indicating problem.

Resume Exit_Proc

Case Else

MsgBox "Error " & Err.Number & " " & Err.Description _
, vbCritical, "frmSetUpSubDefineWeather btnEdit" _
, Err.HelpFile, Err.HelpContext

Resume Exit_Proc

End Select

End Sub

--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "What's UP, Dittoooooo?" - Ditto

[Rick Brandt]

Tim Marshall wrote:
[snip]

COnsider a command button whose only purpose is open a form. The form
to be opened has a number of checks in its on open event. COnsider an
editing form we *don't* want to open if there is no record selected on
the continuous for or sub form datasheet on the calling form. In the
frmSetUpWeather form below, the on open event checks for a currently
selected record (or indeed if there are any records in the calling
form). If this condition fails, then a msgbox explains the problem
and cancel = True.

This will always generate a 2501 error from the calling procedure and
I handle such as shown in the code below. However, this is a lot to
write (though much of it is simply rote with me), so frequently what
I do is knowing the only real error will be the 2501, I do this:

[snip]

What I did for this (and for reports) was create a wrapper function for
OpenForm and OpenReport that traps for and ignores error 2501 just as your
second example does. Now I just use that function instead of the normal
ones and I only had to write the "correct" code once instead of hundreds of
times.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[Anthony England]

"Terry Kreft" <te*********@mps.co.uk> wrote in message
news:3V********************@karoo.co.uk...

Because you should be doing something like:-

Exit_Handler:

If Not rst Is Nothing Then
if rst.state <> adStateClosed then
rst.Close
end if
Set rst = Nothing
End If

Exit Function

Err_Handler:
MsgBox Err.Description, vbExclamation, "Error No: " & Err.Number
Resume Exit_Handler

End Function

If you're in the clean up phase of your code, as you are in the
Exit_Handler, then you need to ensure your code is solid. Personally I
would code it as follows.

Exit_Handler:
On Error resume Next
If Not rst Is Nothing Then
if rst.state <> adStateClosed then
rst.Close
end if
Set rst = Nothing
End If
On Error GoTo 0
Exit Function

Err_Handler:
MsgBox Err.Description, vbExclamation, "Error No: " & Err.Number
Resume Exit_Handler

End Function

On Error Resume Next can get you into infinite loops though, erm trying to
think of an example, Oh yeah this should do it:-

On Error resume Next
Do While (rst.state and adStateOpen) = adStateOpen
rst.Close
Loop
Set rst = Nothing

--
Terry Kreft

Hi Terry
Thanks for the input. I did realise what was causing the error and how the
code to avoid it. The purpose was simply to demonstrate the danger of an
error in the 'clean up and exit' part.
I like your version of the exit procedure - the general policy of which
seems to be:
"Try your very best to avoid any errors in the exit procedure (eg by
checking Is Nothing and rst.State) but realise that there is nothing much to
be done in the event of any unanticipated error and the key thing is to
reliably exit the function. To make double sure of this, put On Error
Resume Next at the beginning and explicitly turn it off at the end with On
Error GoTo 0."

A different policy might be:
"Code in the exit procedure should check for any anticipated eventuality
(such as rst not being initialized or opened) and I am sure that I cannot
predict an error. Therefore, I will use this version of the code and if an
error does occur in testing it will make itself known to me (albeit in an
annoying loop) and I can find out what is happening and I will become
marginally wiser and able to code for this error in the future.

Therefore in my code, I remove the extra two lines of code in the exit
handler:

Exit_Handler:
If Not rst Is Nothing Then
if rst.state <> adStateClosed then
rst.Close
end if
Set rst = Nothing
End If
Exit Function

Another take might be:
"I am so certain that an error cannot occur that I will let an unhandled
runtime error be generated if this does happen - at least I know I'll never
get stuck in a loop"

Exit_Handler:
On Error GoTo 0
If Not rst Is Nothing Then
if rst.state <> adStateClosed then
rst.Close
end if
Set rst = Nothing
End If
Exit Function

After considering these two alternatives, would you still prefer yours? (My
boss says he doesn't f***ing care, he just wishes I'd make a decision one
way or the other and get on with the coding)

[Bri]

Anthony England wrote:

OK I know I am cheating, by now choosing to use ADO instead of DAO, but
consider version 4. It is similar to the version 2 which you approve of.
This function works fine as long as tblContact is there, but if I rename the
table to tblBogus for instance, I get stuck in a never-ending loop caused by
me trying to shut the recordset if it is not nothing (should have checked if
it was actually open).
Now I don't know whether there is any way you can have a DAO recordset which
'is not nothing' but either not to be open or to be un-closable due to some
other reason (** can anyone think of an example??? **). However, this is
possible with ADO and I am concerned with the general principal of
guaranteeing that exit code always exits and never-ending loops cannot
occur.

If you are concerned about errors occurring in your error/exit handlers
you could use the On Error Resume Next statement, but then follow each
subsequent statement with a test for Err.Number<>0 to verify that there
was no error. This also a useful technique for dealing with errors that
you want to test for at specific points in your code rather than just in
general.

So, using your last example as a starting point and showing this
technique in both places that I have mentioned (note that this and the
other examples are to demonstrate the error handling techniques under
discussion only):

Public Function ContactExists4(lngConID As Long) As Boolean
On Error GoTo Err_Handler
Dim rst As ADODB.Recordset
Dim strSQL As String

strSQL = "SELECT tblContact.* FROM tblContact WHERE " & _
"ConID=" & CStr(lngConID)

On Error Resume Next 'want to know that the error occured here
Set rst = New ADODB.Recordset
If Err.Number<>0 Then
MsgBox "Could NOT Set the Recordset"
'Do code that you need to fix this specific error
'and then continue or goto Exit as appropriate
End If
On Error GoTo Err_Handler 'go back to general error handling
rst.Open strSQL, CurrentProject.Connection

If Not rst.EOF Then
ContactExists4 = True
End If

Exit_Handler:
On Error Resume Next
If Not rst Is Nothing Then
rst.Close
If Err.Number<>0 Then
MsgBox "Could NOT close the Recordset"
End If

Set rst = Nothing
If Err.Number<>0 Then
MsgBox "Could not Set rst = Nothing "
End If
End If
On Error Resume 0
Exit Function

Err_Handler:
MsgBox Err.Description, vbExclamation, "Error No: " & Err.Number
Resume Exit_Handler

End Function
--
Bri

[Terry Kreft]

There are three version quoted
1)
On Error resume Next
If Not rst Is Nothing Then
if rst.state <> adStateClosed then
rst.Close
end if
Set rst = Nothing
End If
On Error Goto 0
2)
If Not rst Is Nothing Then
if rst.state <> adStateClosed then
rst.Close
end if
Set rst = Nothing
End If
3)
On Error Goto 0
If Not rst Is Nothing Then
if rst.state <> adStateClosed then
rst.Close
end if
Set rst = Nothing
End If

None of the three should cause a problem as rst is tested to ensure it is
instantiated before the state is tested, having said that if an error did
occur then:-

3) is going to throw bald errors at the user and crash the program

2) I would regard as the worst option as you would get a loop and out of
memory error.

1) hides any errors from the user (errors at this point are trivial anyway)
and carries on with the program.

I would still stick with number 1.
--
Terry Kreft

"Anthony England" <ae******@oops.co.uk> wrote in message
news:dp**********@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com...

"Terry Kreft" <te*********@mps.co.uk> wrote in message
news:3V********************@karoo.co.uk...

Because you should be doing something like:-

Exit_Handler:

If Not rst Is Nothing Then
if rst.state <> adStateClosed then
rst.Close
end if
Set rst = Nothing
End If

Exit Function

Err_Handler:
MsgBox Err.Description, vbExclamation, "Error No: " & Err.Number
Resume Exit_Handler

End Function

If you're in the clean up phase of your code, as you are in the
Exit_Handler, then you need to ensure your code is solid. Personally I
would code it as follows.

Exit_Handler:
On Error resume Next
If Not rst Is Nothing Then
if rst.state <> adStateClosed then
rst.Close
end if
Set rst = Nothing
End If
On Error GoTo 0
Exit Function

Err_Handler:
MsgBox Err.Description, vbExclamation, "Error No: " & Err.Number
Resume Exit_Handler

End Function

On Error Resume Next can get you into infinite loops though, erm trying
to think of an example, Oh yeah this should do it:-

On Error resume Next
Do While (rst.state and adStateOpen) = adStateOpen
rst.Close
Loop
Set rst = Nothing

--
Terry Kreft

Hi Terry
Thanks for the input. I did realise what was causing the error and how
the code to avoid it. The purpose was simply to demonstrate the danger of
an error in the 'clean up and exit' part.
I like your version of the exit procedure - the general policy of which
seems to be:
"Try your very best to avoid any errors in the exit procedure (eg by
checking Is Nothing and rst.State) but realise that there is nothing much
to be done in the event of any unanticipated error and the key thing is to
reliably exit the function. To make double sure of this, put On Error
Resume Next at the beginning and explicitly turn it off at the end with On
Error GoTo 0."

A different policy might be:
"Code in the exit procedure should check for any anticipated eventuality
(such as rst not being initialized or opened) and I am sure that I cannot
predict an error. Therefore, I will use this version of the code and if
an error does occur in testing it will make itself known to me (albeit in
an annoying loop) and I can find out what is happening and I will become
marginally wiser and able to code for this error in the future.

Therefore in my code, I remove the extra two lines of code in the exit
handler:

Exit_Handler:
If Not rst Is Nothing Then
if rst.state <> adStateClosed then
rst.Close
end if
Set rst = Nothing
End If
Exit Function

Another take might be:
"I am so certain that an error cannot occur that I will let an unhandled
runtime error be generated if this does happen - at least I know I'll
never get stuck in a loop"

Exit_Handler:
On Error GoTo 0
If Not rst Is Nothing Then
if rst.state <> adStateClosed then
rst.Close
end if
Set rst = Nothing
End If
Exit Function

After considering these two alternatives, would you still prefer yours?
(My boss says he doesn't f***ing care, he just wishes I'd make a decision
one way or the other and get on with the coding)

[David W. Fenton]

"Anthony England" <ae******@oops.co.uk> wrote in
news:dp**********@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com:

The point under discussion is what happens if an unexpected error
occurs in the ExitFunction part of the code. I cannot give you an
example of an error which I cannot foresee, so I did indeed
introduce a predictable, reproducible error to demonstrate what
would happen if rst.Close failed. If the recordset is DAO, then I
do not know if it is ever possible for <If Not rst Is Nothing Then
rst.Close> to fail. What puzzles me is the worry that On Error
Resume Next will 'spill over' the Exit Function line (despite the
documentation saying this will not happen - and nobody being able
to reproduce this) contrasted with the lack of concern that the
ExitFunction coding could ever cause an error.

Well, the documentation doesn't tell us to clean up these objects in
the first place, because they are supposed to go out of scope and be
cleaned up automatically. If you were relying only on the
documentation, you wouldn't being closing the recordset in the exit
routine and setting it to Nothing in the first place.

As to your last assertion, I have never said nor suggested that the
rst.Close could not under any circumstances throw an error. All I
suggested is that to me, it's better to let the unforeseen error
happen than to prevent it from being reported, which is the upshot
of On Error Resume Next used as you suggest.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

"Rick Brandt" <ri*********@hotmail.com> wrote in
news:hk******************@newssvr12.news.prodigy.c om:

David W. Fenton wrote:

I've never used it in an error handler -- I've only done On Error
Resume exitRoutine.

If I want to ignore an error I use a different label to jump back
to the next line.

It's something I need so seldom that I've never contemplated
using Reume Next in place of a label to jump back to.

Just to clarify. I do not use it in error handlers either. I
just use it in my exit routines when I am closing objects that
might not have been opened due to an error that was handled by my
error handler.

Well, I don't believe in writing code that I know will produce
errors in some cases. I will try to prevent the occurence of the
error, which, so far as I know, is what comparing the object
variable to Nothing does.

I do know there is a situation with DAO database variables where the
variable can be Not Nothing and still not contain a valid database
variable. In my LocalDB() function that I use as a wrapper for a
cached database reference, I trap for the error that occurs if that
is the case.

I much prefer that approach to simply turning off error reporting
because of my bad past experiences with application-wide
unreliability caused by over-reliance on On Error Resume Next.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

Tim Marshall <TI****@PurplePandaChasers.Moertherium> wrote in
news:dp**********@coranto.ucs.mun.ca:

This will always generate a 2501 error from the calling procedure
and I handle such as shown in the code below. However, this is a
lot to write (though much of it is simply rote with me), so
frequently what I do is knowing the only real error will be the
2501, I do this:

Private Sub btnEdit_Click()

On Error Resume Next

DoCmd.OpenForm "frmSetUpWeather", acNormal

On Error GoTo 0

End Sub

Yes, I do realize I should hang my head in shame, but the above
can be easier than the last bit of code shown below.

I've written code like that for reports.

But nowadays I use a subroutine with error handling to open the
reports.

The most frequent error with reports is when the report has an
OnNoData event that closes the report. I forget the error number
produced, but my report opening wrapper subroutine checks for that
and ignores it.

That is, I think, the best way to do these kinds of errors, which
are of a special class, it seems to me. From my point of view,
there shouldn't *be* an error in the calling context just because
the report closed.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

"Terry Kreft" <te*********@mps.co.uk> wrote in
news:3V********************@karoo.co.uk:

Because you should be doing something like:-

Exit_Handler:

If Not rst Is Nothing Then
if rst.state <> adStateClosed then
rst.Close
end if
Set rst = Nothing
End If

Why not just:

If rst.State <> adStateClosed then
rst.Close
End If
Set rst = Nothing

Too bad there is not a corresponding property for DAO recordsets. I
have always worried that checking against Nothing is not a complete
proxy for all the states a DAO recordset can be in. I know for
certain that it is not complete for DAO database variables, which
can be Not Nothing yet not initialized sufficiently to be usable.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

"Anthony England" <ae******@oops.co.uk> wrote in
news:dp**********@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com:

A different policy might be:
"Code in the exit procedure should check for any anticipated
eventuality (such as rst not being initialized or opened) and I am
sure that I cannot predict an error. Therefore, I will use this
version of the code and if an error does occur in testing it will
make itself known to me (albeit in an annoying loop) and I can
find out what is happening and I will become marginally wiser and
able to code for this error in the future.

Therefore in my code, I remove the extra two lines of code in the
exit handler:

Exit_Handler:
If Not rst Is Nothing Then
if rst.state <> adStateClosed then
rst.Close
end if
Set rst = Nothing
End If
Exit Function

This is the policy I've been advocating (though I'd make the code
above simpler, as I suggested in a different post).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Anthony England]

"Terry Kreft" <te*********@mps.co.uk> wrote in message
news:iA********************@karoo.co.uk...

There are three version quoted
1)
On Error resume Next
If Not rst Is Nothing Then
if rst.state <> adStateClosed then
rst.Close
end if
Set rst = Nothing
End If
On Error Goto 0
2)
If Not rst Is Nothing Then
if rst.state <> adStateClosed then
rst.Close
end if
Set rst = Nothing
End If
3)
On Error Goto 0
If Not rst Is Nothing Then
if rst.state <> adStateClosed then
rst.Close
end if
Set rst = Nothing
End If

None of the three should cause a problem as rst is tested to ensure it is
instantiated before the state is tested, having said that if an error did
occur then:-

3) is going to throw bald errors at the user and crash the program

2) I would regard as the worst option as you would get a loop and out of
memory error.

1) hides any errors from the user (errors at this point are trivial
anyway) and carries on with the program.

I would still stick with number 1.
--
Terry Kreft

Thank you for your input. I will take on board the various pros, cons,
experiences and opinions given here and try to come to a decision shortly.

[Anthony England]

"David W. Fenton" <XX*******@dfenton.com.invalid> wrote in message
news:Xn**********************************@127.0.0. 1...

"Anthony England" <ae******@oops.co.uk> wrote in
news:dp**********@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com:

A different policy might be:
"Code in the exit procedure should check for any anticipated
eventuality (such as rst not being initialized or opened) and I am
sure that I cannot predict an error. Therefore, I will use this
version of the code and if an error does occur in testing it will
make itself known to me (albeit in an annoying loop) and I can
find out what is happening and I will become marginally wiser and
able to code for this error in the future.

Therefore in my code, I remove the extra two lines of code in the
exit handler:

Exit_Handler:
If Not rst Is Nothing Then
if rst.state <> adStateClosed then
rst.Close
end if
Set rst = Nothing
End If
Exit Function

This is the policy I've been advocating (though I'd make the code
above simpler, as I suggested in a different post).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Thank you for your input. I will take on board the various pros, cons,
experiences and opinions given here and try to come to a decision shortly.

[Tim Marshall]

Rick Brandt wrote:

What I did for this (and for reports) was create a wrapper function for
OpenForm and OpenReport that traps for and ignores error 2501 just as your
second example does. Now I just use that function instead of the normal
ones and I only had to write the "correct" code once instead of hundreds of
times.

Thanks, Rick.

Honestly, I can't believe I'm such a dumbass as to not to have
considered do the same before. <Insert oath> I do spend a lot of time
when I'm writing procedures to ask myself "can I re-use this? Maybe I
should bang it into a standard form..."

--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "What's UP, Dittoooooo?" - Ditto

[Tim Marshall]

David W. Fenton wrote:

That is, I think, the best way to do these kinds of errors, which
are of a special class, it seems to me. From my point of view,
there shouldn't *be* an error in the calling context just because
the report closed.

Thanks, like I said to Rick, I'm a bit of a dumbass for not considering
making a "wrapper" (does that mean a standard function? I'm not quite
sure what wrapper means, though I've seen the term used frequently here)
function for this sort of thing.

--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "What's UP, Dittoooooo?" - Ditto

[Tim Marshall]

Tim Marshall wrote:

"can I re-use this? Maybe I
should bang it into a standard form..."

Er, that should be "standard module"

--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "What's UP, Dittoooooo?" - Ditto

[David W. Fenton]

Tim Marshall <TI****@PurplePandaChasers.Moertherium> wrote in
news:dp**********@coranto.ucs.mun.ca:

David W. Fenton wrote:

That is, I think, the best way to do these kinds of errors, which
are of a special class, it seems to me. From my point of view,
there shouldn't *be* an error in the calling context just because
the report closed.

Thanks, like I said to Rick, I'm a bit of a dumbass for not
considering making a "wrapper" (does that mean a standard
function? I'm not quite sure what wrapper means, though I've seen
the term used frequently here) function for this sort of thing.

It could be done as a function or as a subroutine. I don't need
anything back from it, so I use a sub, not a function.

You could also instantiate a class object, but that seems to be much
more complex than necessary for the mere task of having an
error-handling wrapper around the process of opening a report.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Terry Kreft]

Because if the ADO rst is not instantiated testing the .state property
throws an error.

Being able to test the state was one of the really nice things I found when
moving to ADO, it came in very useful at the very first customer site I
deployed it to as they had a slow Ethernet network where I had to test the
recordset state after opening to ensure it had finished collecting the data
before continuing.
--

Terry Kreft
"David W. Fenton" <XX*******@dfenton.com.invalid> wrote in message
news:Xn**********************************@127.0.0. 1...

"Terry Kreft" <te*********@mps.co.uk> wrote in
news:3V********************@karoo.co.uk:

Because you should be doing something like:-

Exit_Handler:

If Not rst Is Nothing Then
if rst.state <> adStateClosed then
rst.Close
end if
Set rst = Nothing
End If

Why not just:

If rst.State <> adStateClosed then
rst.Close
End If
Set rst = Nothing

Too bad there is not a corresponding property for DAO recordsets. I
have always worried that checking against Nothing is not a complete
proxy for all the states a DAO recordset can be in. I know for
certain that it is not complete for DAO database variables, which
can be Not Nothing yet not initialized sufficiently to be usable.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Rick Brandt]

Tim Marshall wrote:

David W. Fenton wrote:

That is, I think, the best way to do these kinds of errors, which
are of a special class, it seems to me. From my point of view,
there shouldn't *be* an error in the calling context just because
the report closed.

Thanks, like I said to Rick, I'm a bit of a dumbass for not
considering making a "wrapper" (does that mean a standard function? I'm
not quite sure what wrapper means, though I've seen the term used
frequently here) function for this sort of thing.

I use the term (correctly or not) to to mean any function wrapped around
another in which the outer one provides additional or enhanced functionality
over the one being "wrapped", but which still essentially performs the same
task.

Within the wrapper function the supplied arguments are fed into the function
being wrapped. The only difference is that you can do things before and
after the normal function call that provide the extra functionality that you
want need from the wrapper. In the case being discussed all the wrapper
does is provide the error handler that ignores error 2501.

In the case of my OpenReport wrapper function I added an optional argument
to make the report being opened "fit to window". Since I use that a lot it
was yet another line of code that I was writing over and over again before
creating the wrapper.

When I can I try to make the function signature such that I can change from
the wrapped function to the wrapper function simply by changing the name of
the function and nothing else. This can then even be done with Find and
Replace tools then.

I will freely admit that I could probably examine the code in my apps and
find dozens of other such functions that I could have created and just never
bothered to do so.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[Tim Marshall]

Rick Brandt wrote:

considering making a "wrapper" (does that mean a standard function?

I use the term (correctly or not) to to mean any function wrapped around
another in which the outer one provides additional or enhanced functionality
over the one being "wrapped", but which still essentially performs the same
task.

Thanks Rick, I appreciate your defintion.

--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "What's UP, Dittoooooo?" - Ditto