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". Larry
