I was involved in the C++ standardization process, and argued for
resumption as opposed to termination only in exceptions. I was somewhat
of a pioneer, implementing C++ exceptions for my team to use before
commercial compilers had them. After all, why start a new project with
an old paradigm?
Anyway, as passionate as I was about resumption, or at least making it
not impossible to implement resumption, at the next ANSI meeting the
terminate-only camp made compelling arguments.
I don't remember what the "killer" argument was. But I do remember bits
and pieces: people with real-world experience on systems that have
resumable exceptions in some form ended up never using them; it
complicates the implementation; it is not necessary since callbacks fill
that role already (e.g. new_handler instead of resuming from the
bad_alloc exception); and the semantic concepts of what an exception
means. To elaborate, the code throws when it can't deal with the
situation. What does it mean if the throw worked like a function call
and returned? Code would have to watch out for that, which defeats the
point of making the exception a clean get-away. Really, after fixing
something the function has to start over at the top; e.g. try allocating
again... that's what a loop around the whole try/catch does, and is
today common practice!
So on providing different places to jump to depending on whether the
exception is "fixed" or "not fixed", how is that different from a normal
catch block which can re-throw or drop out?
Consider the error upon trying to open a file. If the open command
contains a callback handler as part of itself, it can try again and
eventually return, transparantly to the caller who just sees that the
file was (eventually) opened. But what if the caller needs to back up
and repeat some steps because of that failure, to get another running
start at the command so to speak? That's what you can do with a
mechanism more elaborate than the callback built into the command. But
you can do that with a try/catch now, having termination semantics,
already. Besides syntactic sugar, how is resuming different from that?
--John
Larry Wall wrote:
On Wed, Jun 14, 2006 at 08:59:02PM -0700, Chip Salzenberg wrote:
: Are Parrot exceptions now, in fact, resumable? If they are, is that
: important? Is anyone actually resuming execution after exception handlers
: are called? I think we _can_ keep resumability, but I'm not sure I want us
: to, and I definitely don't want to bother if no one wants it.
The current thought for Perl 6 is that warnings are essentially just
resumable control exceptions that by default are caught only by the
outermost exception handler, which by default resumes them. But any
exception handler in the dynamic scope may then catch one and turn
it fatal. This gives us dynamic as well as lexical control of warnings
without inventing a mechanism separate from existing control exceptions.
On the other hand, I think we've also said that exceptions are
resumable only if the thrower includes as part of the exception
object a continuation to resume at, which presumably warn() does.
So maybe you don't need to do anything special to make exceptions
resumable for Perl 6, assuming throwing the exception doesn't clobber
the continuation somehow.
On the gripping hand, it looks like this is missing from the specs...
Larry
