Error handling - Resume vs Exit

[Guest]

It seems that most error handling code is designed to display a message
and/or log errors in a table and then exit the procedure altogether. This
may leave some of the calling procedure's code unexecuted, which could be
problematic. Is it considered poor programming practise to resume the
execution of the calling procedure (using Resume Next) after the error
handling is done, rather than exiting the procedure?

 

[Charles E. Vopicka]

i always thought that the point of error handling was to handle the
error. so if it is fixable and can be made non fatal i would say it is
good practice to do that then resume. however sometimes i have noticed
you call something (like an API call) and the only response you get is
success or failure with message. so it isn't always fixable and the
best thing you can do is pass that info on. although i am not a
programmer by training i would say it is not bad practice to resume. if
it was the command wouldn't exist.

It seems that most error handling code is designed to display a message
and/or log errors in a table and then exit the procedure altogether. This
may leave some of the calling procedure's code unexecuted, which could be
problematic. Is it considered poor programming practise to resume the
execution of the calling procedure (using Resume Next) after the error
handling is done, rather than exiting the procedure?

--
Charles E. Vopicka's (Chuck) : (e-mail address removed)

Database Management, GIS Specialist and Research Assistant

Forest Biometrics Research Institute
University of Montana - College of Forestry and Conservation
Missoula, MT 59812
United States of America

Phone:
(406)243-4526
(406)243-4264
(406)549-0647 (Home)

HAVE A NICE DAY (-:

"UNLESS" (The Lorax, by Dr. Seuss)

 

[Guest]

Hi,
I'm also not a programmer by training, but I would like to share my
preferences.Please someone correct me if I am wrong.

I personally prefer to write a Sub or Func only to do a specific task, i.e.
multiple levels of tasks nested in a single Sub or Func are avoided. Hence,
if an error occurs, I believe (?) there is no place else to go except to take
an exit route gracefully. Whatever our preferences are, the philosophy behind
error-handling is to let the Code run smoothly 100 % of the time. If you are
confident you can do this, and consistently, your style is as good as
anybody's.
Some Gods have spoken these words, engraved deep in my mind:
"If there is a way your code can go wrong, your User will always find it"

 

[Scott McDaniel]

It seems that most error handling code is designed to display a message
and/or log errors in a table and then exit the procedure altogether. This
may leave some of the calling procedure's code unexecuted, which could be
problematic. Is it considered poor programming practise to resume the
execution of the calling procedure (using Resume Next) after the error
handling is done, rather than exiting the procedure?

Different situations call for different handling. You have to determine the level of severity of the error, and how it
impacts the rest of the code execution. It's not unusual to Resume Next, if the error is determined to be non-fatal or
you somehow fix the error - for example, if your code expects to open a text file, and the file isn't found, you may
open a FileOpenSave dialog for the user to locate the file ... it that succeeds, you may then use some variantion of
Resume to take the user back to correct place.

However,in many cases you're better off handling things inline before they get to Error ... for example, if your code
MUST have the above mentioned file, you'd be better advised to check for this before the code tries to open it, and
alerting the user if it cannot be found (and, again, perhaps asking for user assistance). Error handling is as much art
as science, and to get good at it you must "think like a user" ... you can bet users aren't going to do processes the
same way you do. Believe me, when you launch your app for the first time you'll end up getting reports of some of the
oddest things that users are doing ... <g>

Scott McDaniel
scott@takemeout_infotrakker.com
www.infotrakker.com

 

[Guest]

BASIC was one of the first places ever to have exception
handling. That's had two effects:

1) Newer languages handle it better
2) There has been a lot added on and taken off over the years.

So you've got a lot of different choices about how you want to
do your exception handling, but you can't do it the way it was
originally designed, and you can't do it the way you would if
you designed it now, in hindsight.

So don't beat yourself up to much about 'proper' design of your
exception handling: you can't get there from here, and even if you
could, some one else would do it different.

For myself, I always capture the exception information and then
Raise all errors back up until they reach the user interface level.
The user interface level decides what if any message to display
or action to take.

And in general, I code my subroutines so that they can be exited
cleanly at any point, so I don't have to worry about clean-up
code.

However, this is not a popular style, and sometimes you do need
clean up code. The most common approach to handling clean-up
code in Access VBA, is to have separate 'catch' and 'always' sections
with your 'try' block. VBA doesn't support separate 'catch' and 'always'
sections in the same way that other languages do now, but there are
three methods that VBA does support
a) Use GOSUB for each try block. This method will amaze all your
friends and amuse your enemies. It works well in VBA but is not
required (and not supported) in any other language, so it's a linguistic
dead end.
b) Use a separate subroutine for each try block. This allows you to
put your 'catch' section inside the subroutine, and the 'always' section
outside the subroutine. This level of complexity is not often required.
c) Use a common 'catch' and 'always' block for all 'try' blocks in a
subroutine. This is the method you will most often see in Access
examples, and created by the Access wizards. If you want to have
multiple try blocks handled differently, you put code into the catch
and always blocks to determine the kind and location of the exception.

Sub fred
on error goto catch_block 'begin try block
do something

Always_block:
on error resume next 'end try block
clean up, close objects etc
exit sub

Catch_block:
display error messages, capture error log
roll back transactions, clear flags etc.
Resume Always_block.
End sub. 'end

You can put separate 'catch' and 'always' blocks into a subroutine,
but there is no way to nest them, and it quickly becomes tiresome.
Realistically, if you want separate catch blocks inside a subroutine,
it is better to put them in line. You do this by using
On Error Resume Next
and testing err.Number to catch exceptions. This is also the way
it is done in VBS, which doesn't support separate catch blocks
at all.

Use On Error Resume Next for inline exception handling, if that
is your preferred style.
Use a 'catch' and 'always' block to clean up code before exit.
From the catch block, resume to the always block.

You could easily use Resume Next if your 'try' block was a
single line, followed immediately by your 'always' block. Theoretically,
there is nothing wrong with that construct. But in reality, such code
is rare. If I saw such code, I would be more amazed by the code
than I would be by the exception handler. When you get to that point,
or if you feel comfortable with having amazing code, then you can
reconsider using 'resume next' :~)

(david)

 

[Guest]

Thanks for taking the time for this long explanation. It helps.

As an aside: I always wondered why Access wizards created simple exception
handling code in the fashion they do. Now I see it's just adhering to an
accepted pattern, but not always needed/useful in the simplest of cases.

ctdak