Re: Draft 3 of RFC 88 version 2.

>>>>> "TO" == Tony Olekshy <[email protected]> writes:

TO> Perl's behaviour after a C<die> starts call-stack unwinding, as
TO> envisioned by this RFC, is as described by the following rules.

TO>   1. Whenever an exception is raised Perl looks for an enclosing
TO>      try/catch/finally clause.

TO>      If such a clause is found Perl traps the exception and proceeds
TO>      as per rule 2, otherwise program shutdown is initiated.

	If an enclosing block is not found, program shutdown is
	initiated.

	Each of the catch blocks associated with the current try
	block are evaluated in order until one catch <expr>
	returns true.

	If none are found the finally block is entered and
	after completing the exception is reraised, and the
	search for an enclosing block continues.

	If a a catch block is entered and completed successfully,
	no succeeding catch block will be tried and processing
	will continue with the finally block (if any) associated
	with the current try.

	A catch block is not considered part of its own try block.
	So that any exception encountered during processing, control
	will continue as if there were no try block at this call
	level and the search for an encloseing block continues.

Does this cover all the cases?

	(Does an exception in a catch go to the finally?)
	(Does an exception in a catch change the exception?)

	
TO>   2. The try block's "next" associated trap/catch or finally clause
TO>      is processed according to rules 3 and 4.  When there are no
TO>      more clauses rule 5 is used.

TO>   3. If a catch <expr> returns true (without itself raising an
TO>      exception), its associated catch block is entered.

TO>      If the catch block is entered and it completes without itself
TO>      raising an exception, the current exception and stack are
TO>      cleared.  But if a catch <expr> or a block clause raises an
TO>      exception, it becomes the current exception, but it does
TO>      not propagate out of the clause (at this point).

TO>      If a catch <expr> raises an exception or returns true, then
TO>      whether or not the catch block raises an exception, any
TO>      succeeding try/catch clauses up to the next finally clause are
TO>      skipped (for the purpose of the "next" iterator in rule 2).

TO>      Processing then continues with rule 2.

TO>   4. When a finally clause is encountered its block is entered.

TO>      If the finally block raises an exception it becomes the current
TO>      exception, but it does not propagate out of the clause (at this
TO>      point).

TO>      Processing continues with rule 2.

TO>   5. After the catch and finally blocks are processed, if there
TO>      is a current exception then it is re-raised and propagated
TO>      as per Rule 1 (beginning above the current try statement in
TO>      the call stack).

TO>      Otherwise $@ is undef, the try statement completes normally,
TO>      and Perl continues with the statement after the try statement.

TO> =head2 Built-In Exception & Error Classes

TO> In addition to the built-in Exception class described below (which
TO> inherits from UNIVERSAL), a built-in Error class is also defined,
TO> which inherits from Exception.

TO> Exceptions raised by the guts of Perl are envisoned by this RFC to
TO> all be instances of classes that inherit from Error.  Instances of
TO> the actual Error class itself are reserved for simple exceptions,
TO> for those cases in which one more or less just wants to say C<throw
TO> Error "My message.">, without a lot of extra tokens, and without
TO> getting into higher levels of the taxonomy of exceptions.

TO> On the other hand, new exception classes that inherit directly from
TO> Exception, as opposed to from Error, are assumed to be asking for
TO> more light-weight functionality.  The intent of this RFC is to
TO> provide a place (Exception) in which methods can be stubbed in for
TO> the functionality required by Errors, so that when they are
TO> overridden by Error they work as expected, but when inherited by
TO> other derivatives of Exception, this error-functionality is avoided
TO> and does not otherwise interfer with the requirements of light-
TO> weight exception handling protocols.  The stack-traceback at throw-
TO> time instance variable, for example, probably doesn't make much
TO> sense when one is throwing success, not failure.

TO> This Exception/Error class factoring is taken advantage of in
TO> this RFC to delegate the details of the Error class to proposals
TO> such as RFC 80 et al, independent of the fact that this RFC expects
TO> such an Error class to inherit from Exception.

TO> =head3 Instance Variables

TO> The built-in Exception and Error classes reserve all instance
TO> variable and method names matching C</^[_a-z]/>.  The following
TO> instance variables are defined.

TO> message

TO>     This is a description of the exception in language intended
TO>     for the "end user".  Potentially sensitive information should
TO>     not be included here.

TO>     This ivar is also used to record the string given when
TO>     C<die "Can't foo."> is used.  Because of stringification
TO>     (described below), C<$@."" eq "Can't foo."> (for some value
TO>     of eq).

TO> tag

TO>     This is a string which module developers can use to assign
TO>     a unique "identifier" to each exception object constructor
TO>     invocation in the module.  A namespace control mechanism
TO>     that helps ensure the uniqueness of tags is described below.

TO> debug

TO>     This is a place for additional description that is not intended
TO>     for the end user (because it is "too technical" or "sensitive").

TO>     For example, in a web application, internal file names might
TO>     be considered sensitive information, but you would still like
TO>     to get the name of the file that couldn't be opened into the
TO>     server log.

TO> object

TO>     If the exception is related to some particular object, this can
TO>     be specified via:

TO> 	throw Exception "...", object => $object;

TO>     This should probably be a weak reference.

TO> trace

TO>     A listref containing a snapshot of the call-stack as at the time
TO>     the exception is first raised.  The array contains hashes (one
TO>     per call stack level), each containing one key-value pair for
TO>     each snapshot value at that level.  Here are some examples:

TO> 	    $e->{trace}->[0]->{file}
TO> 	    $e->{trace}->[0]->{line}
TO> 	    $e->{trace}->[0]->{sub}

TO>     Alternatively, $e->{trace} could be some sort of snapshot object
TO>     thingy.  Similar stuff has been done by the Perl 5 Devel bundle;
TO>     perhaps there should be a Perl 6 RFC for it.

TO>     The functionality of caller() is used to populate this snapshot
TO>     data, but said snapshot has to be taken early and held for
TO>     possible historic debugging use, because usually we want to know
TO>     where we were when things went wrong, I<not> where we were when
TO>     we caught that (by which time, the raise-time stack snapshot
TO>     data is irrecoverable).

TO>     This snapshot data is set up by the "snapshot" method described
TO>     below, so that derived classes that don't want this overhead
TO>     can override that method to do nothing.  This can be important
TO>     to applications that want to use a large number of light-weight
TO>     exceptions to implement non-local success-based flow-control
TO>     gotos, where the cost of taking and maintaining the snapshots
TO>     could prove to be prohibitive, especially since they would
TO>     normally never be used.

TO>     The snapshot method is an overrideable built-in rather than a
TO>     stub though, because in fact in most cases one does want to pay
TO>     the price for being able to debug exceptions, because said price
TO>     is small (in most cases).

TO> severity

TO>     This is some sort of "priority" (such as info v/s fatal) on
TO>     which handing can be based.

TO>     Note that a severity ivar is properly the province of the Error
TO>     class, which is covered in other proposals such as RFC 80.  It
TO>     has been included here to illustrate the kind of functionality
TO>     envisioned by this RFC.

TO> sysmsg

TO>     This a place for the internal exceptions raised by Perl to
TO>     record system information, along the lines of $!, $?, and $^E.

TO>     The use of this ivar is the province of proposals like RFC 80.
TO>     It is provided here as an example of possible functionality.

TO> =head3 Methods

TO> The built-in Exception base class defines the following methods.

TO> new

TO>     Constructs a new object instance, using its arguments as
TO>     a hash to initialize the instance variables by name.

TO>     The "tag" instance variable is treated specially in order
TO>     to control the namespace for tags, as follows:

TO> 	$self->{tag} = $self->settag($arg{tag});

TO> throw

TO>     As a class method a new instance is constucted, passing any
TO>     arguments to the constructor.  This object becomes $self, and
TO>     we now have an instance method.

TO>     As an instance method, any arguments are used to update the
TO>     instance variables (unless just constructed), and this method
TO>     effects C<die $self>.

TO>     This method does not return to local flow control (modulo the
TO>     handler mechanism described below).

TO> handler

TO>     Derived classes may override this method to attempt to "handle"
TO>     an exception or otherwise manipulate it, just before it is raised.
TO>     If handler throws or does not return true the exception is raised,
TO>     otherwise it is not.

TO>     In Exception, this method returns false.

TO>     This makes no sense for Error objects and is abhorent to users
TO>     thereof, but that's ok because Exception's C<handler> method
TO>     returns false, and Error doesn't override it, and, well, Errors
TO>     could use handler for ivar munging as long as they return true.

TO>     However, other uses for Exception (but non-Error) objects may
TO>     want this functionality, at least based on the reference and
TO>     text books which say that classically, an exception has such a
TO>     handler hook.

TO>     If we do provide it, it need not be used, but if we don't
TO>     provide it the functionality cannot otherwise be provided,
TO>     should it be deemed desireable for some application.

TO> C<overload '""'> (Stringification)

TO>     Stringification produces a concatentation of various Exception
TO>     object instance variables and certain delimiters.  The message
TO>     instance variable is always to be included.  The details are to
TO>     be worked out, but an example would be:

TO>     	ABC.1234 [Warning]: Confirmed but not acknowledged.

TO> tag

TO>     This method returns true if

TO> 	    $self->{tag} eq (ref $self) .".". $_[0]

TO>     This allows us to easily trap by namespace-controlled tag,
TO>     using a form like this:

TO> 	    catch $@->tag("Foo") { ... }

TO> settag

TO>     This method effects

TO> 	    $self->{tag} = (ref $self) .".". $_[0];

TO>     This means that the tags provided to exception construcors
TO>     need only be unique across a derived class, which is often
TO>     constrained in such a manner as to make uniqueness relatively
TO>     easy in practice.

TO>     The example of exception class constructor overriding given
TO>     later in this RFC needs to set the tag, while maintaining
TO>     namespace control, without knowing the namespace control
TO>     details, so this method is provided for that.

TO>     Perhaps all this ivar accessor method stuff can be cleaned
TO>     up with other changes to the Perl 6 OO mechanism.

TO> snapshot

TO>     Used internally to generate the "trace" instance variable.
TO>     Designed to be overridden in derived classes for performance
TO>     or extension purposes.  See the description of the trace
TO>     instance variable, above.

TO> show

TO>     This method generates a string formatted version of the
TO>     exception unwinding stack based on the contents of @@,
TO>     stringifying each exception object as it goes.  For example,
TO>     C<print $@->show> produces something like this:

TO> 	    UIM.1234: Can't add a new person to database.
TO> 	    APP.2345: Can't update Company relationship.
TO> 	    DBM.4567: Unable to write to Company table.
TO> 	    IOM.5678: Can't open file ".../company.db".

TO>     C<show> takes the following optional parameters.

TO>     label => 1

TO>         If set, the formatted exception stack is annotated with
TO>         the classes of the objects therein, as in:

TO> 	    Error::UI: UIM.1234: Can't add a new person to database.
TO> 	    Error::DB: APP.2345: Can't update Company relationship.
TO> 	    Error::DB: DBM.4567: Unable to write to Company table.
TO> 	    Error::IO: IOM.5678: Can't open file ".../company.db".

TO>     trace => 1

TO>         If set, the value returned by C<show> includes the Perl
TO>         stack traceback using the information from the *last*
TO> 	exception in the "link" chain (that is, from the point
TO> 	where unwinding first started).  Something like this:

TO> 	    UIM.1234: Can't add a new person to database.
TO> 	    APP.2345: Can't update Company relationship.
TO> 	    DBM.4567: Unable to write to Company table.
TO> 	    IOM.5678: Can't open file ".../company.db".

TO>             Try::throw called from test-403.pl[7].
TO>             Try::try called from test-403.pl[9].
TO>             Try::try called from test-403.pl[11].
TO>             Try::try called from test-403.pl[14].

TO>     debug => 1

TO>         Annotates entries in the unwind stack with the values
TO>         from the Debug option in the throw statements, if any.
TO>         For example:

TO> 	    UIM.1234: Can't add a new person to database.
TO> 	    Debug: Fred Flintstone
TO> 	    APP.2345: Can't update Company relationship.
TO> 	    DBM.4567: Unable to write to Company table.
TO> 	    IOM.5678: Can't open Company file.
TO> 	    Debug: /foo/bar/company.dat

TO> =head3 Custom Exceptions

TO> In addition to the C<exception 'MyException'> mechanism described
TO> above, custom exception and/or error classes can be created along
TO> the following lines:

TO>     File main.pl:

TO> 	use Error::App;

TO> 	exception 'Error_DB', isa => 'Error::App';

TO> 	throw Error_DB "ABC.1234: Can't foo.";

TO>     File Error/App.pm:

TO> 	package Error::App;  @Error::App::ISA = 'Error';

TO> 	sub new
TO> 	{
TO> 	    my ($C, $msg, %opt) = @_;  $C = ref $C || $C;

TO> 	    my $self = $C->SUPER::new($msg, %opt);

TO> 	    $self->{message} =~ s/^([A-Z]+\/\d+):\s+//
TO> 	    and
TO> 		$self->settag($1);

TO> 	    return bless($self, $C);
TO> 	    }

TO>     Without this functionality and the other mechanisms described
TO>     in the RFC, instead of having a way to be able to write

TO> 	throw Error_DB "ABC.1234: Can't write to table $table.";

TO>     a developer would be I<required> to write something like

TO> 	throw Exception::Error::App::DB tag => "ABC.1234",
TO> 	    message => "Can't write to table $table.";

TO>     The latter has a much lower signal to noise ratio than the
TO>     former, which is of significant importance to regular users
TO>     of exception handling mechanisms.

TO>     Note that the scope of classes like Error::App is is limited to
TO>     packages that use it, which presumably want such functionality.

TO> =head1 MOTIVATION

TO> Over the last ten years, the author has come to rely on exception
TO> handling as a relatively robust mechanism for error handling, and
TO> has used exception handling to implement other, non-error related,
TO> non-local flow-control algorithms.  He has developed a relatively
TO> complete implementation of the functionality described herein, in
TO> Perl 5, in the Try.pm module and its associated regression tests
TO> [TRY-2000].  Try.pm in used in large production applications.

TO> The author's motivation is to help Perl 6 achieve a relatively
TO> robust exception handling mechanism that is suitable for error
TO> handling via exceptions, is still capable enough to handle the
TO> needs of production programs, and is still suitable for light-
TO> weight exceptions that may not involve errors at all.

TO> "The Encyclopedia of Software Engineering" [ESE-1994] says (p.847):

TO>     Among the features offered by programming languages to
TO>     support exception handling are the following.

TO>      1. The ability to distinguish the normal control flow from
TO> 	the exception handling flow to make the structure of the
TO> 	program clear.

TO>      2. The ability to detect faults as they occur in the program,
TO> 	not only by explicitly raising an exception but also by
TO> 	implicitly raising it on account of the run-time environment.
TO> 	[...] Both kinds of faults should be handled uniformly.

TO>      3. The ability to transfer control to a programmer-definable
TO> 	exception handler when the fault is detected.  The language
TO> 	should specify the rules by which this a detected fault is
TO> 	bound to its corresponding exception-handling routine.

TO>      4. The ability to specify how control flows after the exception
TO> 	handler is executed, i.e., whether one can resume execution
TO> 	from the point at which it left off, or whether the program
TO> 	should fail.

TO>     Most early programming languages do not provide specific
TO>     features for exception handling, but rather use the normal
TO>     constructs to implement it. [...]  Obviously this and other
TO>     ad hoc methods to not satisfy the requirements listed above.

TO> To this end, new keywords have been deliberately chosen to represent
TO> the new mechanism, in order to make it clear to the developer when
TO> the code is expecting to deal with unwind semantics (rather than
TO> with local flow control).

TO> In addition, the exception handling mechanism propagates exceptions
TO> that are not cleanly caught, which minimizes the chances for the
TO> developer to forget to re-raise uncaught exceptions.  How many of
TO> us check for IO failures after C<print>s?  And if you're writing a
TO> simple program you wouldn't want to, but you would want the program
TO> to shut down after a failure even if you don't check.

TO> Remembering to always check all subroutine and functions for failure
TO> return codes can be difficult, since nothing about the form of the
TO> call, in the source code, indicates whether or not an possible
TO> failure return code is excpected.  And, the exception handling
TO> technique not only works with subroutines and functions, it also
TO> works with operators and with syntax errors.

TO> Although the following code using the new mechanism:

TO>     try     { may_throw_1 }
TO>     catch     may_throw_2   { may_throw_3 }
TO>     finally { may_throw_4 }

TO> can be written in Perl 5 like this:

TO>     eval { may_throw_1 };
TO>     my $unwinding = $@;
TO>     if ($unwinding) {
TO> 	my $test = eval { may_throw_2 };
TO> 	$@ and $unwinding = $@;
TO> 	if ( ! $@ and $test ) {
TO> 	    eval { may_throw_3 };
TO> 	    $unwinding = $@;
TO> 	    }
TO> 	}
TO>     eval { may_throw_4 };
TO>     ($unwinding ||= $@) and die $unwinding;

TO> the opportunity for flow-control errors increases.

TO> =head1 CONVERSION

TO> Although the technique of using exception handing for error
TO> handling often seems foreign at first to developers who are not
TO> used to it, many find that it becomes quite natural when four
TO> concepts are kept in mind.

TO>  1. Wherever you previously would have C<return undef> or some
TO>     other special return code (or a pass-by-reference value),
TO>     to indicate the failure of a subroutine or function, instead
TO>     use C<throw Error> (or some fancier form thereof).

TO>  2. Wherever you previously would have written

TO> 	$x = foo();  defined $x or return undef;

TO>     to propagate an error from a callee back to your caller, you
TO>     can just write C<$x = foo();> because unhandled exceptions
TO>     automatically propagate.

TO>  3. Wherever you previously would have written the equivalent of the
TO>     following to do something about an error and then propagate it

TO> 	$x = foo();
TO> 	unless (defined $x) {
TO> 	    # do something about error
TO> 	    return undef;
TO> 	    }

TO>     you can now write

TO> 	try { $x = foo(); }
TO> 	catch {
TO> 	    # do something about error
TO> 	    }

TO>  4. Wherever you previously would have ignored an error in order
TO>     to allow you to restore invariants or enforce postconditions,
TO>     and then C<return undef> to propagate the error, like this:

TO> 	open F, ...;
TO> 	$x = foo();
TO> 	close F;
TO> 	defined $x or return undef;

TO>     you can now write

TO> 	open F, ...;
TO> 	try     { $x = foo(); }
TO> 	finally { close F;    }

TO>     because unhandled exceptions automatically propagate.

TO> =head1 ISSUES

TO> Object Model

TO>     This RFC is written using the basic Perl 5 concept of an object
TO>     as a reference to a blessed hash containing instance variable
TO>     name-value pairs.  It may need to be modified to account for
TO>     any new basic Perl 6 object model.

TO> Syntax

TO>     If C<catch EXPR { ... }> proves to be difficult for Perl to
TO>     parse, even in the form C<catch EXPR => { ... }> then the form
TO>     C<trap { EXPR } catch { ... }> is a possible alternative (based
TO>     on earlier versions of this RFC and mailing list discussions
TO>     thereto).

TO> Lexical Scope

TO>     If it is not possible to have try, catch, and finally blocks
TO>     share lexical scope (due, perhaps, to the vagueries of stack
TO>     unwinding), this feature can simply be deleted, and the outer
TO>     scope can be shared.

TO>     This matter will have to be referrred to the good folks over
TO>     in internals.

TO> Keyword Names

TO>     RFC 88 only introduces the try, throw, trap, catch, finally,
TO>     and exception keywords, which are all traditionally related
TO>     to exception handling.  And they don't even need to all be
TO>     keywords, some can be functions (depending on the Perl 6
TO>     parser).

TO>     The "throw" verb was chosen for raising an exception, because
TO>     of its neutral connotation (unlike "fail" for example), because
TO>     exceptions do not necessarily encapsulate a negative.

TO>     New kewords were chosen so that this can be written:

TO> 	try {
TO> 	    try {
TO> 		try     { ... }
TO> 		finally { ... }
TO> 		}
TO> 	    catch Error1 { ... }
TO> 	    catch Error2 { ... }
TO> 	    catch        { ... }
TO> 	    }
TO> 	catch { print $@, "\n"; }

TO>     instead of cognitively overloading existing keywords and
TO>     concepts in a manner like this:

TO> 	eval {
TO> 	    eval {
TO> 		eval     { ... }
TO> 		continue { ... }
TO> 		}
TO> 	    else {
TO> 		switch ($@) {
TO> 		    case /First/  { ... }
TO> 		    case /Second/ { ... }
TO> 		    else          { ... }
TO> 		    }
TO> 		}
TO> 	    }
TO> 	else { print $@, "\n"; }

TO>     because the author is of the opinion that overloading else and
TO>     continue with unwind semantics not traditionally associated with
TO>     else and continue can be confusing, especially when intermixed
TO>     with local flow-control forms of else and continue (which may
TO>     be present in any { ... } block), or when an "else die $@" is
TO>     forgotten on a switch that needs to re-throw.

TO>     Some perl6-language-error discussions have suggested leaving out
TO>     the try altogether, as in simply writing C<{ } else { }>.  Yikes!

TO>     The "try" is not for Perl's sake.  It's for the developers's
TO>     sake.  It says, watch out, some sort of non-local flow control
TO>     is going on here.  It signals intent to deal with action at a
TO>     distance (unwinding semantics).  It satisfys the first rule
TO>     listed under MOTIVATION.

TO> retry

TO>     There has been some discussion on perl6-language-error about
TO>     the concept of re-entering try blocks on catch, and the
TO>     possibility of using such a mechanism to replace AUTOLOAD.

TO>     The author is of the opinion that in order to do this sort
TO>     of thing properly one should use continuations, which are
TO>     being discussed elsewhere to this RFC.

TO>     The intent of this RFC is to provide a simple yet robust
TO>     exception handling mechanism that is suitable for error
TO>     handling, not for replacing AUTOLOAD.

TO> eval

TO>     The semantics of eval are, "don't unwind unless the user re-dies
TO>     after the eval".  The semantics of try are "unwind after try
TO>     unless any raised exception was cleanly and completely handled".

TO>     In the author's opinion, both eval and try should exist in Perl
TO>     6.  This would also mean that the legacy of examples of how to
TO>     use eval in Perl will still work.

TO>     And, of course, we still need C<eval $string>.

TO>     However, discussions on perl6-language-errors have shown that
TO>     some would prefer the eval { ... } form to be removed from Perl
TO>     6, because having two methods of exception handling in Perl
TO>     which could be confusing to developers.  This would in fact be
TO>     possible, since the same effect can be achieved with:

TO> 	    my $e;
TO> 	    try { ... } catch { $e = $@ }
TO> 	    # now process $e instead of $@

TO>     However, it would be necessary to provide some way to clear
TO>     the otherwise read-only $@ and @@ variables, should that
TO>     functionality be deemed desireable.

TO> try v/s eval

TO>     Some participants in discussions on perl6-language-errors have
TO>     expressed the opinion that not only should C<eval> be used
TO>     instead of C<try>, but C<else> should be used instead of
TO>     multiple C<catch> blocks.  One advantage of their approach is
TO>     that you can use an expression for the exception you wish to
TO>     catch in a C<switch> block:

TO> 	  eval { ... }
TO> 	  else {
TO> 	      switch ($@) {
TO> 		  case ^_->isa('Error::IO') { ... }
TO> 		  case ^_->my_method        { ... }
TO> 		  }
TO> 	      }

TO>     In this case, the problem arises, how should the code implicitly
TO>     rethrow uncaught exceptions?  Without having to look inside the
TO>     C<switch> statement to see what it did?  Most of the proponents
TO>     of this model think that uncaught exceptions should not be
TO>     implicitly rethrown; one suggests that the programmer should
TO>     C<undef $@> at the end of every successful <case> block, so that
TO>     perl rethrows any C<$@> still extant at the end of the C<else>.

TO>     This RFC allows a switch to be used in a catch { ... } clause,
TO>     for cases where that approach would minimize redundant code in
TO>     catch <expr> { ... } clauses, but with the mechanism proposed in
TO>     this RFC, the switch functionality shown above can be written
TO>     like this, while still maintaining the automatic exception
TO>     propagation when no cases match, and while saving 4 lines and
TO>     two levels of indenting:

TO> 	try { ... }
TO> 	case Exception::IO { ... }
TO> 	case $@->my_method { ... }

TO>     From a minimalist point of view, C<else> is an plausible suggestion
TO>     that should be considered if this RFC is evaluated as requiring
TO>     too many new keywords.  Our objection to it is that it requires
TO>     the programmer to insert C<undef $@> in every instance of by far
TO>     the most common type of clause, which tends to be an extreemly
TO>     risky error-prone technique.

TO> Exception Base Class

--> Some of these now belong in Error, and therefore RFC 80 et al.

TO>     The following questions about Exception should be addressed.

TO>     How to extend ivars and control namespace?
TO>     How to extend methods and control namespace?
TO>     Default values for tag and severity?
TO>     How to categorize severity?
TO>     How to arrange the exception class hierarchy for the Perl core?
TO>     How to tag exceptions in the Perl core?
TO>     What assertions should be placed on the instance variables?
TO>     What should stringification return?
TO>     What can be delegated to Error for performance?

TO> Exception/Error Factorization

TO>     The author is of the opinion that these classes should be
TO>     factored as an architectural matter.  However, they could
TO>     be merged, resulting in some simplification of this RFC.

TO>     One advantage of leaving them factored is that changes to the
TO>     Error class, over the life of Perl 6, will not, a prior, affect
TO>     the use of Exception by those who need light-weight exception
TO>     objects for their algorithm.

TO> Handler

TO>     Some participants in discussions on perl6-language-errors
TO>     currently prefer that the functionality represented by
TO>     the handler method of the Exception class not be include at
TO>     all.  Should that be deemed to be the case, the C<handler>
TO>     method of the Exception class can be left out.

TO>     It has also been mentioned that we should consider making
TO>     overriding of throw impossible, so that throw must die.

TO>     Independent of the matter of throw and handler methods, there
TO>     should be I<no way> to disable the raising of exceptions on
TO>     some sort of "global" level.

TO> Mixed Flow Control

TO>     Some of the reference texts, when discussing exception
TO>     handling, refer to the matter that it may be difficult to
TO>     implement a C<go to> across an unwinding semantics block,
TO>     as in:

TO> 	    try { open F, $f } catch { next; }

TO>     This matter will have to be referrred to the good folks over
TO>     in internals.  If this functionality is not possible, it can
TO>     always be implemented with lexical state variables instead.

TO> Core Functionality

TO>     If the guts of Perl 6 are to use exceptions for errors, some
TO>     of the stuff in this RFC has to go into the guts of Perl 6.

TO>     On the other hand, if Perl 6 decides to stay with just eval,
TO>     die, and $@, then the functionality of this RFC can still
TO>     be provided by a (core) module, along the lines of that
TO>     implemented (with different syntax), in Perl 5, in [TRY-2000].
TO>     The actual syntax used would depend on what parser extentions
TO>     are available in Perl 6.

TO> Stack Snapshot Object

TO>     This RFC mentions that an exception's C<trace> instance variable
TO>     could point to a "stack snapshot" object, rather than to a data
TO>     structure.  A mechanism like this is available in the Perl 5
TO>     Devel bundle.  If an RFC for such a snapshot class is added to
TO>     Perl 6, this RFC should be reconciled with it.

TO> $SIG{__DIE__}

TO>     The try, catch, and finally clauses localize and undef
TO>     $SIG{__DIE__} before entering their blocks.  This behaviour
TO>     can be removed if $SIG{__DIE__} is removed.

TO>     If $SIG{__DIE__} is not removed, it should be invoked as
TO>     at the phrase "program shutdown is initiated" in Rule 1,
TO>     not at the time an exception is raised.

TO>     If the old functionality is removed, do we want to introduce
TO>     such functionality to Rule 1 anyway, and some way to nest
TO>     handlers?

TO> RFC 96

TO>     Should be withdrawn as it is by the same author as this RFC
TO>     and he says it is now covered here.

TO> =head1 IMPACT

TO> Legacy

TO>     It is not the intent of this RFC to interfer with traditional
TO>     Perl scripts; the intent is only to facilitate the availability
TO>     of a more controllable, pragmatic, and yet robust mechanism when
TO>     such is found to be appropriate.

TO>     Nothing in this RFC impacts the tradition of simple Perl scripts.

TO>     C<die "Foo";> continues to work as before.

TO>     In fact, as described above, this stuff could all still be done
TO>     in a (core) module.

TO>     There is no need to use try, catch, or finally, if one doesn't
TO>     want to, and in most of the cases where one would want to use
TO>     them, it takes less source code with exceptions than with return
TO>     code checking (as per the CONVERSION section above).

TO> RFC 63: Exception handling syntax proposal.

--> Impact statement not ready for this draft.

TO> RFC 70: Allow exception-based error-reporting.

--> Impact statement not ready for this draft.

TO> RFC 80: Exception objects and classes for builtins.

--> Impact statement not ready for this draft.

TO> RFC-119: Object neutral error handling via exceptions.

--> Impact statement not ready for this draft.

TO> Traditional eval, $@, and die functionality.

TO>     $@ is now always wrapped up in an Exception object, unless
TO>     it already isa Exception object.  $@ can now only be set by
TO>     die, and cleared by eval.

TO> =head1 ACKNOWLEDGEMENTS

TO> This RFC is based on invaluable support on a number of fronts.

TO> This RFC has been refined with the help of (via the perl6 mailing
TO> lists) contributions in particular from Peter Scott, with additional
TO> input from Chaim Frenkel, Graham Barr, and Jonathan Scott Duff, and
TO> via conversations with Jim Hoover.

TO> The Perl 5 implementation of Try.pm [TRY-2000] has been used by the
TO> staff of Avra Software Lab Inc. for production code, it has been
TO> debated in presentations at the Software Engineering Research Lab
TO> at the University of Alberta, and it has been discussed on the
TO> perl-friends mailing list.  At one point it was refined based on
TO> the study of Graham Barr's C<Error.pm> module [GBE-1999].

TO> =head1 REFERENCES

TO> ESE-1994: The Encyclopedia of Software Engineering, J.J. Marciniak
TO>           (editor), John Wiley & Sons Inc, 1994.  ISBN 0-471-54002-1

TO> GBE-1999: Graham Barr's C<Error.pm> module.
TO> 	  http://search.cpan.org/doc/GBARR/Error-0.13/Error.pm

TO> RFC-63:   Exception handling syntax proposal.
TO> 	  http://tmtowtdi.perl.org/rfc/63.pod

TO> RFC-70:   Allow exception-based error-reporting.
TO> 	  http://tmtowtdi.perl.org/rfc/70.pod

TO> RFC-80:   Exception objects and classes for builtins.
TO> 	  http://tmtowtdi.perl.org/rfc/80.pod

TO> RFC-96:   A Base Class for Exception Objects
TO> 	  http://tmtowtdi.perl.org/rfc/96.pod

TO> RFC-119:  Object neutral error handling via exceptions.
TO> 	  http://tmtowtdi.perl.org/rfc/119.pod

TO> RYK-1989: Computer Architecure, Hardware and Software, R.Y.Kain,
TO> 	  volume 1, Prentice-Hall Inc., 1989.  ISBN 0-13-166752-1

TO> TRY-2000: Try.pm version 1.1.3.6, Avra Software Lab Inc., 2000.
TO> 	  http://www.avrasoft.com/perl/rfc/try-1136.zip

TO> =head1 REVISIONS

TO> Version 1, 2000-08-08: Based on Avra Software Lab Inc's Try.pm,
TO> redaction 1.1.3.6.

TO> Version 2 (draft 3), 2000-08-19: Reflects changes made based on
TO> discussion in the various perl6-language lists since 2000-08-08.




-- 
Chaim Frenkel					     Nonlinear Knowledge, Inc.
[email protected]				               +1-718-236-0183