Re: coroutines and continuations ( in Python? - long discussion )

Guido.van.Rossum@cwi.nl
Tue, 03 May 1994 23:02:52 +0200

> >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. :-(

This shuld be solved by Lance's signal handling module -- the default
SIGINT handler will then raise KeyboardInterrupt. Until then, I'm not
going to change things. (Hey Lance! How's it going?)

> >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?

Hook functions would be defined with an interface that would allow
them to mend things. This depends very much on the kind of problem to
be mended. I was thinking of very specific hooks for very specific
situations -- not a general "hook" mechanism to be invoked where
currently exceptions are used.

> I still think an exception object (as proposed a while ago) would give
> a cleaner interface than all this special "hook" stuff.

I must admit I don't remember how exception objects were defined. Was
this during one of my absences?

--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>
URL: <http://www.cwi.nl/cwi/people/Guido.van.Rossum.html>

PS I junked the -k flag tonight. It felt really good cutting out
those lines of code :-)