Error handling question

  • Thread starter Thread starter BruceM
  • Start date Start date
B

BruceM

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 said:
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?
Click to expand...
 
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 said:
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?
Click to expand...

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).
 
Thanks for the reply. My responses are inline.

Klatuu said:
If you remove the Else, the message box will be presented for every error
encountered.
Click to expand...

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"
Click to expand...

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.
 
Rick Brandt said:
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).
Click to expand...
 
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?
 
Fred said:
Dear Rick:

Any chance you might share those functions? ;)
Click to expand...

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
 
BruceM said:
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?
Click to expand...

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?
 
If I have a command button for SendObject that opens an e-mail, and if I
then click the X at the top right of the e-mail without sending it, I will
get an Error 2501 (the Send Object action was canceled, or something like
that) message if I do not trap the error.
 
Thanks, Rick!


Fred

Rick Brandt said:
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
Click to expand...
 
BruceM said:
If I have a command button for SendObject that opens an e-mail, and
if I then click the X at the top right of the e-mail without sending
it, I will get an Error 2501 (the Send Object action was canceled, or
something like that) message if I do not trap the error.
Click to expand...

Then the code that calls SendObject has to trap for Error 2501 and ignore it
(or whatever else you want to do when that happens).
 
Thanks, that was what I figured. I have been doing that, but as I said, I
keep writing the same lines of error message and error handling code (msgbox
"Error #" ... etc.) for each event. I had hoped there was a way to avoid
the redundancy. I suspect not. It is not a big deal. I appreciate the
time you have put into the replies.
 
BruceM said:
Thanks, that was what I figured. I have been doing that, but as I
said, I keep writing the same lines of error message and error
handling code (msgbox "Error #" ... etc.) for each event. I had
hoped there was a way to avoid the redundancy. I suspect not. It is
not a big deal. I appreciate the time you have put into the replies.
Click to expand...

Just as I did with functions for OpenForm and OpenReport you could create a
custom "wrapper function" that you use instead of SendObject. Within that
function you still use SendObject passing it all of the arguments that your
wrapper function uses and then you write the erorr handler in your custom
function that ignores error 2501.

Now you just use the wrapper function instead of SendObject directly and no
longer need to keep writing the error handler over and over again.
 
I can see where that technique could come in handy, and not just with
SendObject. I need to learn to look for opportunities to eliminate some of
the repetition that is inevitable with code. Thanks for pointing me in that
direction, and thanks too for all of your comments and suggestions on this
topic.
 
Back
Top