>4) I don't think that it would be a good idea to allow exceptions to
>be restarted, even if it were possible. They are generally used in
>situations where there is no sensible course of action possible. If a
EXCEPT for KeyboardInterrupt, which can be triggered anywhere and is
hard to trap in such a way that you can always reenter the codeblock.
I still have no fool-proof way to ignore KeyboardInterrupt or create a
handler that terminates your program if you wish, but continues
otherwise. :-(
>mending possibility exists in a particular situation I think defining
>a "hook" function would be more appropriate -- the default hook could
>raise the exception or the code calling the hook could raise the
>exception if the hook didn't fix the problem. Anyway, most exceptions
That would be convenient, and solve the problem above. How does the
"hook" function fix the problem? By returning a special value?
I still think an exception object (as proposed a while ago) would give
a cleaner interface than all this special "hook" stuff.
-Jaap-
-- Jaap Vermeulen +--------------------------+ | Sequent Computer Systems | Internet : jaap@sequent.com | Beaverton, Oregon | Uucp : ...uunet!sequent!jaap +--------------------------+