Error handling question

I use something like the following for error handling when there is an error
that I want to trap:

ProcErr:
If Err.Number = 2501 Then
GoTo ProcExit
Else
msgbox "Error #" & Err.Number & ", " & Err.Description & " -
Control Name"
Resume ProcExit
End If

Would it make any difference if I eliminated the Else thus:

ProcErr:
If Err.Number = 2501 Then
GoTo ProcExit
End If
msgbox "Error #" & Err.Number & ", " & Err.Description & " - Control
Name"
Resume ProcExit

Also, can I streamline this process in some way, or eliminate the need to
enter the same code over and over? Are there other considerations I should
take into account, or is this effective error handling?

"BruceM" wrote:

I use something like the following for error handling when there is an error
that I want to trap:

ProcErr:
If Err.Number = 2501 Then
GoTo ProcExit
Else
msgbox "Error #" & Err.Number & ", " & Err.Description & " -
Control Name"
Resume ProcExit
End If

Would it make any difference if I eliminated the Else thus:

ProcErr:
If Err.Number = 2501 Then
GoTo ProcExit
End If
msgbox "Error #" & Err.Number & ", " & Err.Description & " - Control
Name"
Resume ProcExit

Also, can I streamline this process in some way, or eliminate the need to
enter the same code over and over? Are there other considerations I should
take into account, or is this effective error handling?

If you remove the Else, the message box will be presented for every error
encountered. I don't understand what you mean by "enter the same code over
and over"

"BruceM" wrote:

I use something like the following for error handling when there is an error
that I want to trap:

ProcErr:
If Err.Number = 2501 Then
GoTo ProcExit
Else
msgbox "Error #" & Err.Number & ", " & Err.Description & " -
Control Name"
Resume ProcExit
End If

Would it make any difference if I eliminated the Else thus:

ProcErr:
If Err.Number = 2501 Then
GoTo ProcExit
End If
msgbox "Error #" & Err.Number & ", " & Err.Description & " - Control
Name"
Resume ProcExit

Also, can I streamline this process in some way, or eliminate the need to
enter the same code over and over? Are there other considerations I should
take into account, or is this effective error handling?

BruceM wrote:
I use something like the following for error handling when there is
an error that I want to trap:

ProcErr:
If Err.Number = 2501 Then
GoTo ProcExit
Else
msgbox "Error #" & Err.Number & ", " & Err.Description &
" - Control Name"
Resume ProcExit
End If

Would it make any difference if I eliminated the Else thus:

ProcErr:
If Err.Number = 2501 Then
GoTo ProcExit
End If
msgbox "Error #" & Err.Number & ", " & Err.Description & " -
Control Name"
Resume ProcExit

Also, can I streamline this process in some way, or eliminate the
need to enter the same code over and over? Are there other
considerations I should take into account, or is this effective error
handling?

I created my own functions for opening reports and forms. They take the
exact arguments as the built in ones except they automatically ignore error
2501. This eliminates having to write the error trap every time (you just
have to remember to use the custom function).



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

Dear Rick:

Any chance you might share those functions?


Cheers!
Fred Boer

"Rick Brandt" wrote in message
t...
BruceM wrote:
I use something like the following for error handling when there is
an error that I want to trap:

ProcErr:
If Err.Number = 2501 Then
GoTo ProcExit
Else
msgbox "Error #" & Err.Number & ", " & Err.Description &
" - Control Name"
Resume ProcExit
End If

Would it make any difference if I eliminated the Else thus:

ProcErr:
If Err.Number = 2501 Then
GoTo ProcExit
End If
msgbox "Error #" & Err.Number & ", " & Err.Description & " -
Control Name"
Resume ProcExit

Also, can I streamline this process in some way, or eliminate the
need to enter the same code over and over? Are there other
considerations I should take into account, or is this effective error
handling?

I created my own functions for opening reports and forms. They take the
exact arguments as the built in ones except they automatically ignore
error
2501. This eliminates having to write the error trap every time (you just
have to remember to use the custom function).



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

Thanks for the reply. My responses are inline.

"Klatuu" wrote in message
...
If you remove the Else, the message box will be presented for every error
encountered.

I should have mentioned that at the beginning of the procedure I have:

Or Error GoTo ProcErr

Also, before the ProcErr code I have:

ProcExit:
Exit Sub

Does that clear up my question? It seems to me that if the code (without
the Else) encounters Error 2501, it will go to ProcExit, and the message box
code will not be run. If it encounters another error, it will check to see
if the error is 2501, and when it is not will proceed with the msgbox part
of the ProcErr code. If there is no error then the code will run until it
reaches ProcExit.

I don't understand what you mean by "enter the same code over
and over"

I was not clear. I was referring just to the msgbox part of ProcErr. I may
have quite a few procedures, in each of which I would like to include error
handling. The msgbox line is the same in all procedures that do not include
error trapping, meaning that I enter the same line of code again and again,
except for the name of the Event at which the error has occurred. It's not
that big a deal, I suppose, but it does seem a bit redundant.


"BruceM" wrote:

I use something like the following for error handling when there is an
error
that I want to trap:

ProcErr:
If Err.Number = 2501 Then
GoTo ProcExit
Else
msgbox "Error #" & Err.Number & ", " & Err.Description & " -
Control Name"
Resume ProcExit
End If

Would it make any difference if I eliminated the Else thus:

ProcErr:
If Err.Number = 2501 Then
GoTo ProcExit
End If
msgbox "Error #" & Err.Number & ", " & Err.Description & " - Control
Name"
Resume ProcExit

Also, can I streamline this process in some way, or eliminate the need to
enter the same code over and over? Are there other considerations I
should
take into account, or is this effective error handling?

"Rick Brandt" wrote in message
t...
BruceM wrote:
I use something like the following for error handling when there is
an error that I want to trap:

ProcErr:
If Err.Number = 2501 Then
GoTo ProcExit
Else
msgbox "Error #" & Err.Number & ", " & Err.Description &
" - Control Name"
Resume ProcExit
End If

Would it make any difference if I eliminated the Else thus:

ProcErr:
If Err.Number = 2501 Then
GoTo ProcExit
End If
msgbox "Error #" & Err.Number & ", " & Err.Description & " -
Control Name"
Resume ProcExit

Also, can I streamline this process in some way, or eliminate the
need to enter the same code over and over? Are there other
considerations I should take into account, or is this effective error
handling?

I created my own functions for opening reports and forms. They take the
exact arguments as the built in ones except they automatically ignore
error
2501. This eliminates having to write the error trap every time (you just
have to remember to use the custom function).



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

There may be a blank message before this one. I think I clicked the Send
button too soon.

Thanks for responding. I like the idea of the custom function, since I
often need to trap Error 2501, but I'm not quite certain how to make it
work. If I have a command button for SendObject (to send an e-mail, for
instance), and if the user decides against sending the e-mail, how do I trap
that when opening the form? Would I make a function to trap 2501, then call
the function in place of the If ... End If part of the ProcErr code? Or am
I missing your point?

"Rick Brandt" wrote in message
t...
BruceM wrote:
I use something like the following for error handling when there is
an error that I want to trap:

ProcErr:
If Err.Number = 2501 Then
GoTo ProcExit
Else
msgbox "Error #" & Err.Number & ", " & Err.Description &
" - Control Name"
Resume ProcExit
End If

Would it make any difference if I eliminated the Else thus:

ProcErr:
If Err.Number = 2501 Then
GoTo ProcExit
End If
msgbox "Error #" & Err.Number & ", " & Err.Description & " -
Control Name"
Resume ProcExit

Also, can I streamline this process in some way, or eliminate the
need to enter the same code over and over? Are there other
considerations I should take into account, or is this effective error
handling?

I created my own functions for opening reports and forms. They take the
exact arguments as the built in ones except they automatically ignore
error
2501. This eliminates having to write the error trap every time (you just
have to remember to use the custom function).



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

Fred Boer wrote:
Dear Rick:

Any chance you might share those functions?

Pretty basic stuff really (once you see them I'm sure you'll agree).

The one for the report adds an option for Fit-To-Window, You will have to
replace my custom ErrorMessages function with whatever you normally use for
displaying error messages.


'Wrapper for DoCmd.OpenForm that ignores error 2501
'*******************************************
Public Function fnOpenForm(stFormName As String, _
Optional lngView As Long =
acNormal, _
Optional stFilterName As
String, _
Optional stWhereCondition As
String, _
Optional lngDataMode As Long =
acFormPropertySettings, _
Optional lngWindowMode As Long
= acNormal, _
Optional stOpenArgs As String)
As Boolean

On Error GoTo ErrHandler

DoCmd.OpenForm stFormName, lngView, stFilterName, stWhereCondition,
lngDataMode, lngWindowMode, stOpenArgs
fnOpenForm = IsLoaded(stFormName)

Egress:
Exit Function

ErrHandler:
Select Case Err.Number
Case 2501
'ignore
Case Else
ErrorMessages "fnOpenForm Function"
End Select
Resume Egress
End Function

'Wrapper for DoCmd.OpenReport that ignores error 2501
'*********************************************
Public Function fnOpenReport(stReportName As String, _
Optional lngView As Long =
acViewNormal, _
Optional stFilterName As
String, _
Optional stWhereCondition As
String, _
Optional FitToWindow As
Boolean) As Boolean

On Error GoTo ErrHandler

DoCmd.OpenReport stReportName, lngView, stFilterName, stWhereCondition
fnOpenReport = IsRptLoaded(stReportName)
If FitToWindow = True Then DoCmd.RunCommand acCmdFitToWindow

Egress:
Exit Function

ErrHandler:
Select Case Err.Number
Case 2501, 2046
'ignore
Case Else
ErrorMessages "fnOpenReport Function"
End Select
Resume Egress
End Function


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

BruceM wrote:
There may be a blank message before this one. I think I clicked the
Send button too soon.

Thanks for responding. I like the idea of the custom function, since
I often need to trap Error 2501, but I'm not quite certain how to
make it work. If I have a command button for SendObject (to send an
e-mail, for instance), and if the user decides against sending the
e-mail, how do I trap that when opening the form? Would I make a
function to trap 2501, then call the function in place of the If ...
End If part of the ProcErr code? Or am I missing your point?

Not sure I understand the question. If you are pressing a button that calls
SendObject what does that have to do with opening a form?

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