Opinions on error handling

[Joel Wiseheart]

I'll open this up for debate: How do you determine whether
you should include error handlers in a procedure? Should
error handlers be included in code such as:

Private Sub VendorCode_GotFocus()
'Purpose: Autodrop the Vendor Code field if enabled.

Me!VendorCode.Dropdown

End Sub

Does a single line of code, or two or three lines of code
warrant error handlers? Is there some other criteria for
determining if some can be left out?

I'm sure everyone has different opinions on this. I'm
interested in hearing different points of view.

Thanks!

 

[Graham Mandeno]

Hi Joel

My philosophy is that you should NEVER have an unhandled error. You may
decide that the probability of an error occurring is zero, in which case you
might take the risk of omitting an On Error statement, but you must
recognise that it *is* a risk.

You may decide that you want to ignore any error which occurs, by using On
Error Resume Next. This is fine, especially in a short, inconsequential
procedure. However, this still constitutes error handling. It's just that
the action taken by the handler is to ignore the error and continue to the
next statement.

--
HTH!
Graham Mandeno [Access MVP]
Auckland, New Zealand

Return mail address is invalid in a vain attempt to reduce spam.
Feedback is welcome at: (e-mail address removed)
Please post new questions or followups to newsgroup.

 

[Graham Mandeno]

Hi Joel

My philosophy is that you should NEVER have an unhandled error. You may
decide that the probability of an error occurring is zero, in which case you
might take the risk of omitting an On Error statement, but you must
recognise that it *is* a risk.

You may decide that you want to ignore any error which occurs, by using On
Error Resume Next. This is fine, especially in a short, inconsequential
procedure. However, this still constitutes error handling. It's just that
the action taken by the handler is to ignore the error and continue to the
next statement.

--
HTH!
Graham Mandeno [Access MVP]
Auckland, New Zealand

Return mail address is invalid in a vain attempt to reduce spam.
Feedback is welcome at: (e-mail address removed)
Please post new questions or followups to newsgroup.

 

[Ben]

Joel-
FWIW- I tend to agree with Graham, there should never be
unhandled errors. Inasmuch as some code *should* never
cause an error, these are usually inconsequential bits
that can be handled with on error resume next. The
example you cited *should* never cause an error, but what
if (and I don't know) an error is triggered if there are
no items in the list, or the control is not visible? I
think it's better to handle an error by saying 'aw, I
don't care' than to give an ugly, meaningless (to the
user) message to that poor user. (Users are not always
poor, programmers almost always are ;-)
Remember that the user is ALWAYS going to screw up your
code. When you're testing, you *know* what is supposed to
go in a field, and you put it there to make sure your
code works, unfortunatly, users tend to be unkind and put
silly things in forms (i.e. "My ex-wife sucks" in the due
date field). You can validate and handle these things,
but its good to also have a catch all error handler, even
for simple stuff, to take care of anything you didn't
think of. I can't tell you how many times I left out an
error handler and spent a lot of time walking code to
figure out that something silly F'ed the whole thing up.
Anyway, sorry to be long winded, but I guess I've become
a bit passionate about error handling. I think I need a
hobby.
Ben

-----Original Message-----
Hi Joel

My philosophy is that you should NEVER have an unhandled error. You may
decide that the probability of an error occurring is zero, in which case you
might take the risk of omitting an On Error statement, but you must
recognise that it *is* a risk.

You may decide that you want to ignore any error which occurs, by using On
Error Resume Next. This is fine, especially in a short, inconsequential
procedure. However, this still constitutes error handling. It's just that
the action taken by the handler is to ignore the error and continue to the
next statement.

--
HTH!
Graham Mandeno [Access MVP]
Auckland, New Zealand

Return mail address is invalid in a vain attempt to reduce spam.
Feedback is welcome at: (e-mail address removed)
Please post new questions or followups to newsgroup.

I'll open this up for debate: How do you determine whether
you should include error handlers in a procedure? Should
error handlers be included in code such as:

Private Sub VendorCode_GotFocus()
'Purpose: Autodrop the Vendor Code field if enabled.

Me!VendorCode.Dropdown

End Sub

Does a single line of code, or two or three lines of code
warrant error handlers? Is there some other criteria for
determining if some can be left out?

I'm sure everyone has different opinions on this. I'm
interested in hearing different points of view.

Thanks!

.

 

[Ben]

Joel-
FWIW- I tend to agree with Graham, there should never be
unhandled errors. Inasmuch as some code *should* never
cause an error, these are usually inconsequential bits
that can be handled with on error resume next. The
example you cited *should* never cause an error, but what
if (and I don't know) an error is triggered if there are
no items in the list, or the control is not visible? I
think it's better to handle an error by saying 'aw, I
don't care' than to give an ugly, meaningless (to the
user) message to that poor user. (Users are not always
poor, programmers almost always are ;-)
Remember that the user is ALWAYS going to screw up your
code. When you're testing, you *know* what is supposed to
go in a field, and you put it there to make sure your
code works, unfortunatly, users tend to be unkind and put
silly things in forms (i.e. "My ex-wife sucks" in the due
date field). You can validate and handle these things,
but its good to also have a catch all error handler, even
for simple stuff, to take care of anything you didn't
think of. I can't tell you how many times I left out an
error handler and spent a lot of time walking code to
figure out that something silly F'ed the whole thing up.
Anyway, sorry to be long winded, but I guess I've become
a bit passionate about error handling. I think I need a
hobby.
Ben

-----Original Message-----
Hi Joel

My philosophy is that you should NEVER have an unhandled error. You may
decide that the probability of an error occurring is zero, in which case you
might take the risk of omitting an On Error statement, but you must
recognise that it *is* a risk.

You may decide that you want to ignore any error which occurs, by using On
Error Resume Next. This is fine, especially in a short, inconsequential
procedure. However, this still constitutes error handling. It's just that
the action taken by the handler is to ignore the error and continue to the
next statement.

--
HTH!
Graham Mandeno [Access MVP]
Auckland, New Zealand

Return mail address is invalid in a vain attempt to reduce spam.
Feedback is welcome at: (e-mail address removed)
Please post new questions or followups to newsgroup.

I'll open this up for debate: How do you determine whether
you should include error handlers in a procedure? Should
error handlers be included in code such as:

Private Sub VendorCode_GotFocus()
'Purpose: Autodrop the Vendor Code field if enabled.

Me!VendorCode.Dropdown

End Sub

Does a single line of code, or two or three lines of code
warrant error handlers? Is there some other criteria for
determining if some can be left out?

I'm sure everyone has different opinions on this. I'm
interested in hearing different points of view.

Thanks!

.

 

[Allen Browne]

A few years back, I was caught with an error that I didn't think would
happen. Experience says that it takes less effort to always include the
error handler than it does to figure out whether an error could ever occur
or not.

The only exception I make is if the single line of code is a call to an
procedure that does contain error handling. Even then, you have to be
absolutely certain that the call cannot fail. For example, if the proc.
accepts an argument that is a Long and you pass in an Null, the call fails.

 

[Allen Browne]

A few years back, I was caught with an error that I didn't think would
happen. Experience says that it takes less effort to always include the
error handler than it does to figure out whether an error could ever occur
or not.

The only exception I make is if the single line of code is a call to an
procedure that does contain error handling. Even then, you have to be
absolutely certain that the call cannot fail. For example, if the proc.
accepts an argument that is a Long and you pass in an Null, the call fails.

 

[Larry Daugherty]

Add to all of the good arguments that have gone before for ALWAYS handling
errors; consider that some random event in the system could cause an error.
If you've distributed your application as an MDE using the runtime an
unhandled error will dump your application.

HTH

 

[Larry Daugherty]

Add to all of the good arguments that have gone before for ALWAYS handling
errors; consider that some random event in the system could cause an error.
If you've distributed your application as an MDE using the runtime an
unhandled error will dump your application.

HTH

 

[Joel Wiseheart]

Thanks for all the comments!

One of the things Graham and Ben said that I think helps
is using the "On Error Resume Next" structure. The single
line helps accomodate those "one-liners."

I guess I'm wondering where you draw the line between full
error handlers and "Resume next" statements. I'm also
wondering how all of this error handling can affect speed
and performance of loading and executing Forms, in
particular. For example, when you turn this:

Private Sub VendorCode_GotFocus()
'Purpose: Autodrop the Vendor Code field if enabled.

Me!VendorCode.Dropdown

End Sub

Into this, with the error handler:

Private Sub VendorCode_GotFocus()
'Purpose: Autodrop the Vendor Code field if enabled.
On Error GoTo Error_VendorCode_GotFocus

Me!VendorCode.Dropdown

Exit_VendorCode_GotFocus:
Exit Sub

Error_VendorCode_GotFocus
MsgBox (Err.Number & " " & Err.Description)
Resume Exit_VendorCode_GotFocus

End Sub

This just seemed to me like a lot of code, having 6 lines
of error handling code, to handle a single line of code
for a combo box drop-down command.

I think the Resume Next works good in this case, since if
the code only has one statement, and it causes an error,
the next step is to exit the subroutine anyway.

-----Original Message-----
Joel-
FWIW- I tend to agree with Graham, there should never be
unhandled errors. Inasmuch as some code *should* never
cause an error, these are usually inconsequential bits
that can be handled with on error resume next. The
example you cited *should* never cause an error, but what
if (and I don't know) an error is triggered if there are
no items in the list, or the control is not visible? I
think it's better to handle an error by saying 'aw, I
don't care' than to give an ugly, meaningless (to the
user) message to that poor user. (Users are not always
poor, programmers almost always are ;-)
Remember that the user is ALWAYS going to screw up your
code. When you're testing, you *know* what is supposed to
go in a field, and you put it there to make sure your
code works, unfortunatly, users tend to be unkind and put
silly things in forms (i.e. "My ex-wife sucks" in the due
date field). You can validate and handle these things,
but its good to also have a catch all error handler, even
for simple stuff, to take care of anything you didn't
think of. I can't tell you how many times I left out an
error handler and spent a lot of time walking code to
figure out that something silly F'ed the whole thing up.
Anyway, sorry to be long winded, but I guess I've become
a bit passionate about error handling. I think I need a
hobby.
Ben

-----Original Message-----
Hi Joel

My philosophy is that you should NEVER have an unhandled error. You may
decide that the probability of an error occurring is zero, in which case you
might take the risk of omitting an On Error statement, but you must
recognise that it *is* a risk.

You may decide that you want to ignore any error which occurs, by using On
Error Resume Next. This is fine, especially in a short, inconsequential
procedure. However, this still constitutes error handling. It's just that
the action taken by the handler is to ignore the error and continue to the
next statement.

--
HTH!
Graham Mandeno [Access MVP]
Auckland, New Zealand

Return mail address is invalid in a vain attempt to reduce spam.
Feedback is welcome at: (e-mail address removed)
Please post new questions or followups to newsgroup.

I'll open this up for debate: How do you determine whether
you should include error handlers in a procedure? Should
error handlers be included in code such as:

Private Sub VendorCode_GotFocus()
'Purpose: Autodrop the Vendor Code field if enabled.

Me!VendorCode.Dropdown

End Sub

Does a single line of code, or two or three lines of code
warrant error handlers? Is there some other criteria for
determining if some can be left out?

I'm sure everyone has different opinions on this. I'm
interested in hearing different points of view.

Thanks!

.

.

 

[Joel Wiseheart]

Thanks for all the comments!

One of the things Graham and Ben said that I think helps
is using the "On Error Resume Next" structure. The single
line helps accomodate those "one-liners."

I guess I'm wondering where you draw the line between full
error handlers and "Resume next" statements. I'm also
wondering how all of this error handling can affect speed
and performance of loading and executing Forms, in
particular. For example, when you turn this:

Private Sub VendorCode_GotFocus()
'Purpose: Autodrop the Vendor Code field if enabled.

Me!VendorCode.Dropdown

End Sub

Into this, with the error handler:

Private Sub VendorCode_GotFocus()
'Purpose: Autodrop the Vendor Code field if enabled.
On Error GoTo Error_VendorCode_GotFocus

Me!VendorCode.Dropdown

Exit_VendorCode_GotFocus:
Exit Sub

Error_VendorCode_GotFocus
MsgBox (Err.Number & " " & Err.Description)
Resume Exit_VendorCode_GotFocus

End Sub

This just seemed to me like a lot of code, having 6 lines
of error handling code, to handle a single line of code
for a combo box drop-down command.

I think the Resume Next works good in this case, since if
the code only has one statement, and it causes an error,
the next step is to exit the subroutine anyway.

-----Original Message-----
Joel-
FWIW- I tend to agree with Graham, there should never be
unhandled errors. Inasmuch as some code *should* never
cause an error, these are usually inconsequential bits
that can be handled with on error resume next. The
example you cited *should* never cause an error, but what
if (and I don't know) an error is triggered if there are
no items in the list, or the control is not visible? I
think it's better to handle an error by saying 'aw, I
don't care' than to give an ugly, meaningless (to the
user) message to that poor user. (Users are not always
poor, programmers almost always are ;-)
Remember that the user is ALWAYS going to screw up your
code. When you're testing, you *know* what is supposed to
go in a field, and you put it there to make sure your
code works, unfortunatly, users tend to be unkind and put
silly things in forms (i.e. "My ex-wife sucks" in the due
date field). You can validate and handle these things,
but its good to also have a catch all error handler, even
for simple stuff, to take care of anything you didn't
think of. I can't tell you how many times I left out an
error handler and spent a lot of time walking code to
figure out that something silly F'ed the whole thing up.
Anyway, sorry to be long winded, but I guess I've become
a bit passionate about error handling. I think I need a
hobby.
Ben

-----Original Message-----
Hi Joel

My philosophy is that you should NEVER have an unhandled error. You may
decide that the probability of an error occurring is zero, in which case you
might take the risk of omitting an On Error statement, but you must
recognise that it *is* a risk.

You may decide that you want to ignore any error which occurs, by using On
Error Resume Next. This is fine, especially in a short, inconsequential
procedure. However, this still constitutes error handling. It's just that
the action taken by the handler is to ignore the error and continue to the
next statement.

--
HTH!
Graham Mandeno [Access MVP]
Auckland, New Zealand

Return mail address is invalid in a vain attempt to reduce spam.
Feedback is welcome at: (e-mail address removed)
Please post new questions or followups to newsgroup.

I'll open this up for debate: How do you determine whether
you should include error handlers in a procedure? Should
error handlers be included in code such as:

Private Sub VendorCode_GotFocus()
'Purpose: Autodrop the Vendor Code field if enabled.

Me!VendorCode.Dropdown

End Sub

Does a single line of code, or two or three lines of code
warrant error handlers? Is there some other criteria for
determining if some can be left out?

I'm sure everyone has different opinions on this. I'm
interested in hearing different points of view.

Thanks!

.

.