I'd like to add a little more.  The context of the original throw
probably knows best whether it's even possible or sensical to
continue, so it should be optional whether the exception contains a
resume continuation.  The presence of the continuation signals that
the inner code would *like* to continue but can't figure out how
without more dynamic context, where that could even include human
interaction on some level.  The absence of a resume continuation
means someone thinks this dynamic branch needs a wooden stake through
its heart.

But thinking about optional continuations, another thing occured
to me.  It's always bugged me that warnings were something different
from exceptions, and now I think we can unify them, if we say that
a warning is simply an exception with two properties.  The first is
that it's in a category that, by default, the outermost runtime will
just report on and resume.  And the second is, of course, that the
resume continuation is required.  So turning any warning into a
fatal error consists of stripping the resume continuation.  (Which
might mean that the presence of the continuation is what differentiates
warnings from fatal errors, but I doubt it.  There needs to be a
class of exceptions that have a resume continuation that is not resumed
by default.  A "die" should throw that kind of exception, and have
a reasonably expectation of not being resumed in the normal course of
things.  Nevertheless, a "die" is well formed enough that we know where
it should resume if it forced into a warning instead.)

This gives us the ability to capture any warning in the dynamic
scope and do something about it.  (Whether it should by default
pop up in a CATCH block or a CONTROL block, or have a WARN block
of its own, I don't know.)  But this gives us dynamic control over
warnings to complement (not replace) the lexical control provided by
"use warnings".


Reply via email to