develooper Front page | perl.perl6.language | Postings from September 2005

Re: Exceptuations

Thread Previous | Thread Next
From:
Yuval Kogman
Date:
September 28, 2005 15:18
Subject:
Re: Exceptuations
Message ID:
20050928221814.GB29485@woobling.org
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
like:

	given $! {
		when Exception::ResumesByDefault {
			old_exception_handler($!);
		}

		... # the body of the CATCH
	}

and 

> 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 {
		temp &*EXCEPTION_HANDLER := &*OUTER::EXCEPTION_HANDLER;
		&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
	&*EXCEPTION_HANDLER:

		multi cont (Exception::Control::Redo) {
			body.goto(*$current_binding_tuple);
		}

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



-- 
 ()  Yuval Kogman <nothingmuch@woobling.org> 0xEBD27418  perl hacker &
 /\  kung foo master: /me climbs a brick wall with his fingers: neeyah!



Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About