In order to support continuable exception generators, here is a style guide for exception values, and an observation on what exceptions should support at the language level:
* Exceptions should preserve data
All exceptions should contain as much of the original data that
caused them...
With Luke's new theory proposal, storing the argument tuple for the
call the raised the exception is logical. For example, for a
Permission Denied error raised in open() we should have access to
the filename that we tried to open, and the mode we tried to open it
with.
* Each thrown exception should contain the value of $! from before
it was thrown
* Each thrown exception has to know whether it was thrown because of
'use fatal' or because of an explicit 'die'
* fail should be used except for very strict conditions
* use fatal should be encouraged by the documentation, for one
liners, scripts, and full blown apps.
* Context data should be overridable at the exception object level
Carp and friends should be implemented not by using a different
keyword than fail, but failing with a value that specifies a certain
context.
sub croak (*$a) { # tuples again
fail Exception.new(*$a, :position($?CALLER::CALLER::POSITION));
}
* fail should cascade such that every time a block is left with a
failing return value, the block's caller should be checked for use
fatal.
* When continuing into an exception, the parameters to the
continuation are substituted for the error.
use fatal;
my $value = {
fail "foo";
CATCH {
$!.continue("bar");
}
}
say $bar;
Continuing into the exception with no arguments is like ignoring
'use fatal' for this specific exception, causing the failed value to
propagate out of the fatalized block.
--
() Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker &
/\ kung foo master: /me wields bonsai kittens: neeyah!!!!!!!!!!!!!!!!
pgpE7Wb5OOFbg.pgp
Description: PGP signature
