Smart solution for abort/retry/ignore error handling

[Nimral]

Hi folks,

is there a smart way to develop efficiently that helps me in the
following situation: a sub calls a subsub, which calls a subsubsub,
and so on.

Within a subsubsub an error occurs which I handle, either using on
error goto / err.number, or a try... catch block. I display a msgbox
(abort,retry,ignore). Implementing retry and ignore is fairly easy
using a loop structure. But how about "abort"?

First of all I do not, of course, want to terminate the whole
application using an end statement.

What I would want ist to continume execution somewhere near the end of
the sub where the chain of calls originated, do some cleanup work, and
then resume the main form routine of my program.

Cleanly terminating each sub until I reach the originating sub ist a
lot of clumsy code.

I have seen that try ... catch blocks come pretty close to what I have
in mind, but I haven't figured out yet wether I can simply use one by
willingly triggering the catched exception somewhere in a sub-sub (if
so ... how is this done), or wether there is another way to get what I
want.

Thanks,

Armin.

[\(O\)enone]

Nimral wrote:

Within a subsubsub an error occurs which I handle, either using on
error goto / err.number, or a try... catch block. I display a msgbox
(abort,retry,ignore). Implementing retry and ignore is fairly easy
using a loop structure. But how about "abort"?

How about creating yourself a new exception class, perhaps an
ApplicationAbortException.

Then when the user selects to abort, you can throw a new
ApplicationAbortException up to the calling procedure.

Each procedure which has an exception handler should specifically try to
catch ApplicationAbortExceptions, and if one is caught it can perform
whatever tidying up is required, and then re-throw the exception back up to
its calling procedure.

Would that do what you want?

Alternatively, you could abort your app by using a call to
Application.Exit(), and then put all your tidy up code inside Finally blocks
(which is where it should be anyway, of course). Application.Exit()
provides a quick way of closing your application, but unlike the End
statement (which IMO is evil and should never be used) it does ensure that
all the Finally blocks are called.

--

(O)enone