Do you use On Error, Err_, Exit_ ??

[Maarkr]

I ran across an access db that had all code references to On Error, Err_,
and Exit_ stripped out... it looked so clean and i was wondering how many
people actually do this? I can understand how some of my code does have some
necessary error handling routines, but for a simple form opening or
run-of-the-mill command button code from a wizard, should I clean up the
stuff that microsoft adds in? As an example compare:

Private Sub Command18_Click()
On Error GoTo Err_Command18_Click

Dim stDocName As String
Dim stLinkCriteria As String

stDocName = "Wx_radar"
DoCmd.OpenForm stDocName, , , stLinkCriteria

Exit_Command18_Click:
Exit Sub

Err_Command18_Click:
MsgBox Err.Description
Resume Exit_Command18_Click

End Sub

--here's the same thing condensed and stripped down:

Private Sub Command18_Click()
DoCmd.OpenForm "Wx_radar"
End Sub

What do you think?

 

[fredg]

I ran across an access db that had all code references to On Error, Err_,
and Exit_ stripped out... it looked so clean and i was wondering how many
people actually do this? I can understand how some of my code does have some
necessary error handling routines, but for a simple form opening or
run-of-the-mill command button code from a wizard, should I clean up the
stuff that microsoft adds in? As an example compare:

Private Sub Command18_Click()
On Error GoTo Err_Command18_Click

Dim stDocName As String
Dim stLinkCriteria As String

stDocName = "Wx_radar"
DoCmd.OpenForm stDocName, , , stLinkCriteria

Exit_Command18_Click:
Exit Sub

Err_Command18_Click:
MsgBox Err.Description
Resume Exit_Command18_Click

End Sub

--here's the same thing condensed and stripped down:

Private Sub Command18_Click()
DoCmd.OpenForm "Wx_radar"
End Sub

What do you think?

Well they are not the same thing.
The code with the error handling code appears to have been written by
the command button wizard. It always sets up variables (such as
stDocName and stLinkCriteria) even though it doesn't use all of them,
and always uses error handling, assigning the command button name to
the Exit and Error Handling names.
If this code cannot find the named form it will give you an Access
generated message and exit the sub.

The second code does not use error handling and assigns the form name
directly without use of a variable. It is certainly more condensed.

If the second code errors out because the form "Wx_radar" can't be
found, Access will generate it's own error message which, at times,
can be rather obtuse, and offers no alternative handling.

You can use either method as long as you know what you are doing.
Here is an adaptation that will provide alternative error handling,
yet be condensed.

Private Sub Command18_Click()
On Error GoTo Err_Handler

DoCmd.OpenForm "Wx_radar"

Exit_Sub:
Exit Sub

Err_Handler:
If Err = 2102 then
' That form does not exist so open a different form and continue
DoCmd.OpenForm "Alternative Form"
Else
' There has been an error so get that error number and description
' so that we can write it down and 'fix' it.
MsgBox "Error #: " & Err.Number & " " & Err.Description
' then clear the error and exit the sub
End If
Resume Exit_Sub

End Sub

I would suggest you not use the control names generated by Access.
"Command18" gives you no indication of what the button does. Months
from now you will have forgotten.
"cmdOpenWxRadarForm" might be a better name, as it will tell you,
months from now, exactly what that button does.

 

[Michel Walsh]

Given that error reported to end user are mostly useful in the cases where
the user can do something about it ( like no floppy disk in the floppy disk
reader, impossible to navigate at a given www reference, etc.), as example,
what the end user can do if your form Wx_radar is not open-able, my error
handling is generally limited to data validation, at places where end user
can still do something about it. Otherwise, when the end user can't hardly
do anything, I use an on error continue with safe-guards taking the form of
debug.assert err.number=0 at critical point, just to be sure that result the
code produces did NOT run over a "silent" error, just about to be displaying
garbage. Indeed, ASSERTions are much more useful than error handling for the
DEVELOPER, ie, in cases where the end user cannot do anything, but where the
developer can do something to correct it (bug), since assert can cover and
run-time error, as described, AND logic error (which run-time error
handling cannot handle anyway).



Vanderghast, Access MVP

 

[BeWyched]

Hi Maarkr

Don't underestimate users' ability to c*ck-up even the most simpliest of
routines.

Without exception I will always use error-capture no matter how simple the
coding might be. The alternative is, potentially, a 'Critical Error' bomb-out
which has to be the most embarrasing response for a commercial application.

I would respectively suggest that routines without error-capture are a sure
sign of an amateur!

I suggest you digest fredg and Michel Walsh's replies which are excellent
and choose which suits you best.

Cheers.

BW

 

[dch3]

The *very* first thing that I do when I create a new SUB or FUNCTION is to
insert the error handling. (Thank you MZTools!)

The error handling is *critical* especially when you're deploying the
application as you can never predict what might happen when its used in the
day to day operation. Its especially needed if you create a .MDE file as
you're users could be presented with rather interesting and bizarre results
if an error is thrown.

For convenince's sake, all of my error handler's rely on a generic public
function to build the specific error message to be presented by passing the
error number, form name and procedure name to the generic function. I also
log the error in a table to capture it for later review and a general
understanding if there's code that tends to crap out more than other code.

So YES!.

 

[Dymondjack]

Use a global error handler (mine is xHandler, x being the prefix for any
error-related data)


Private Sub btnOpen_Click()
On Error GoTo Err_btnOpen_Click
DoCmd.OpenForm "Wx_radar"

Exit_btnOpen_Click
Exit Sub

Err_btnOpen_Click:
xHandler(Err.Number, Err.Description) 'ect ect

End Sub


And in your modErrors (or whatever you want to name it)

Public Sub xHandler(lngErrNum as Long, strErrDesc As String) As Long

'Handle your error accordingly

End Sub


Global error handlers are a way to handle every type of error that may
occur, and they are always the backbone of my applications. When used
properly they should handle logging of user information, error information,
or even certain events that should take place if a certain error code passes
as an argument.

Agreed that stripping any code from its error handling is a disaster waiting
to happen...

Happy Coding!