Re: Error handling - Resume vs Exit

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


"david@epsomdotcomdotau" wrote:

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)

"ctdak" <ctdak@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:B363D964-2ACE-461A-BC49-F80E6F484AD1@xxxxxxxxxxxxxxxx
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?




.

Relevant Pages

  • Re: Error handling - Resume vs Exit
    ... BASIC was one of the first places ever to have exception ... do your exception handling, but you can't do it the way it was ... VBA doesn't support separate 'catch' and 'always' ... Use a separate subroutine for each try block. ...
    (microsoft.public.access.modulesdaovba)
  • Re: Practical error/exception handling...
    ... Could I humbly suggest that the requirement for a 'standard' way of handling ... But I only need the exception handler in ... > and is informative to both user and developer when errors occur. ...
    (alt.comp.lang.borland-delphi)
  • Re: Ignore SQL Server 2000 store proc errors and still get results?
    ... catch (Exception ex) ... > You definitely don't want to do 30 round trips by handling the logic ... > temp table in your stored procedure to handle the collection of valid ... >>> expensive in both server and client code. ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Rationale behind unwind-protect and double errors
    ... try/finally exception handling system. ... C++ programmers usually use destructors for the same purpose. ... handling, which does not use the mechanism you outline. ...
    (comp.lang.lisp)
  • Re: on error against try..catch
    ... This is one point where try/cast can help as you can catch only those ... exception that are of a given class. ... > in some routine like mousemove, graphical drawing etc i sometimes i use ... >>> if exception handling is better like i think how can i do to pass from ...
    (microsoft.public.dotnet.general)
Loading