On Wed, Sep 28, 2005 at 09:49:11 -0700, Larry Wall wrote:
> 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.

So CATCH does set the &*EXCEPTION_HANDLER continuation to be something

        given $! {
                when Exception::ResumesByDefault {

                ... # the body of the CATCH


> or have a WARN block of its own, I don't know.

Or maybe &*EXCEPTION_HANDLER is a multi-method-continuation.

CATCH could simply be a macro that compiles to

        ENTER {
                &EXCEPTION_HANDLER.add_variant(cont (Exception::Fatal $!) {


BTW, how do we declare continuations explicitly? Or is it just a sub
that is directly .goto'd ?

An MMD exception handler that is extended in the dynamic scope is
cool because it's not limitied to just control exceptions, warnings,
and fatal errors.

Some fun definitions:

        every loop construct creates some lexical bindings in the body:

                &next - throws an Exception::Control::Next
                &redo - throws an Exception::Control::Redo
        Entering the loop adds temporary variants to

                multi cont (Exception::Control::Redo) {

                multi cont (Exception::Control::Next) {

 ()  Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418  perl hacker &
 /\  kung foo master: /me climbs a brick wall with his fingers: neeyah!

Attachment: pgpiYc6duPVGk.pgp
Description: PGP signature

Reply via email to