This might not be a database question, but the other newsgroup I dropped it in
looked like it was even more off topic.

I would like to know if there is an elegant way of exiting multiple levels of
sub
procedures.

lets say:

sub1(){
   etc...
   call sub2()
   etc...

[DROP to sub1] is what I don't know how to do:

You cannot say: goto sub1 because goto labels must be in the same procedure.
(It would not be a good thing to do anyway because it would be bad for the call
stack, but you can't do it and pragmatically determine how bad it would be. . .
as far as I know.)

I looked into faking an error condition, so that errors are propigated up
through the caller and all subs say on error goto the end of the sub and exit,
but this

did not work, because error conditions would only last one level. - - - it
still may be possible to do it this way, but I do not know how.

Another approach would be to have some process lurking which allows you to
cancel something it called. (This would be the way of doing it if it was
multithreaded but as far as I know VB is not multithreaded in any way)

A way that would work but that I am trying to avoid would be to exit the sub
normally then right after the call test the same condition and branch if
necessary to the end.  I want to limit the number of places I am asking the
same question and this requires asking the same question many many times all
over the place.

None of these approaches worked for me.  I would definately appreciate
someone's experience and insight.

David Tollefson

Regards,

Fritz

Thanks,
I figured it out.  You can do it using the
Err.raise method.

I tried this the last time I looked at the problem, but it would not work,
because the code was in a form. . . it must be in a module for this method to
work.

lets say you have a button that you'd like to use to cancel a tree of
subs/functions.  The button
sets a global variable GetOut = True

Somewhere in all the leaf subs in loops that
run often you say:
on error goto er
... etc ...
if GetOut then
    err.raise 3000, "location", "GetOut"
endif
... etc ...
er:
if err.number = 3000 then
     err.raise 3000, "location", "GetOut"
else
   {handle real errors}
endif

all subs which could be higher in the calls list
must have the on error goto
and the
er:
  if err.number = .. .. etc ...

as above.

I worked on this problem a long time ago, and
the fact that it wouldn't work on forms tricked
me (raising the error after the error handling
label would not propigate the error upward through the calls list but stop
execution)

-- David Tollefson