| Note: these documents may be out of date. Do not use as reference! |
To see what is currently happening visit http://www.perl6.org/
Exception objects and classes for builtins
Maintainer: Peter Scott <peter@psdt.com> Date: 9 Aug 2000 Last Modified: 3 Oct 2000 Mailing List: perl6-language-errors@perl.org Number: 80 Version: 4 Status: Frozen
This RFC proposes that builtins that throw exceptions throw them as objects belonging to a set of standard classes. This would enable an exception type to be easily recognized by user code. The behavior if the exception were not trapped should be identical to the current behavior (error message with optional line number output to STDERR and exit with non-zero exit code).
This RFC is tightly bound with RFC 88, which proposes an exception handling mechanism based upon exceptions-as-objects, and in particular specifies that fatal exceptions thrown by the core will be objects with certain instance attributes. We assume here that these aspects of RFC 88 are implemented.
Builtins experiencing fatal errors currently call die, which is to say,
they throw an exception. Builtins experiencing non-fatal errors return a
variety of error codes. RFC 70 proposes that these be trappable exceptions
if use Fatal is in effect.
This RFC proposes that both exceptions be objects blessed into a standard set of classes which can be checked for by the user.
The exception object will have attributes filled in by perl. The applicable attributes from RFC 88 will be used, including:
RFC 88 eschews numeric codes in favor of alphanumeric tags. A system
exception should place the symbolic errno constant here, e.g., EINVAL,
for system errors; something will have to be made up for errors that don't
have associated errnos.
The text of the exception, e.g., "Out of memory".
Relative level of fatality. Chosen from some TBD enumeration, e.g., "Warning", "Fatal", "Information".
Additional information about the exception, the kind of thing currently put
in $^E.
This and the next two attributes are used to track the program locations
the exception has passed through to this point since it was thrown. This
attribute returns an array of filenames, starting with the one in which the
exception was thrown. This is to preserve caller-type information for
the catcher to be able to see. RFC 88 proposes the method show and
option trace to retrieve filenames and line numbers.
An array of line numbers of program locations the exception has passed through between being thrown and being caught.
An array of (package-qualified) subroutine names the exception has passed through between being thrown and being caught.
Stringifying the object itself will yield the message attribute. A
facility attribute was suggested to indicate what part of perl is
throwing the exception: IMO that is part of the exception class. In an
numeric context, the value will be the errno if it corresponds to one,
otherwise up to the implementor.
This is a strawman exception class enumeration. The merits of this RFC do
not depend on this being a good list, only on it being possible to
find a reasonable one. A common prefix like Exception:: is elided for
readability.
Note: conceivably, the implementation could allow an exception to belong to
more than one class at a time through multiple inheritance (e.g., Regex
and Recursion). I haven't explored the ramifications of that.
These class names can be specified in calls to Fatal.pm (and appropriate
language currently appears in RFC 70), qualified with a : to distinguish
them from core function names. This allows the user to change the fatality
or otherwise of whole classes of exceptions. It would be possible (whether
it would also be desirable is another matter) for a user to say, e.g.,
no Fatal qw(:Reference) and thereby excise the usual core exception upon
an incorrect dereference operation, as though they had wrapped it in an
eval. This makes the operation of Fatal.pm consistent over the
broadest possible application.
Divide by zero and friends.
malloc failed, request too large, that sort of thing.
A compilation error occurred in eval, /e, or (?{ ... }). Possible
candidate for subdividing.
A syntax error occurred in a regex (built at run-time). Possible candidate for subdivision.
An I/O error occurred. Almost certainly should be subdivided, perhaps
parallel to the IO:: hierarchy.
Error in format given to pack, printf, octal/hex/binary number
etc. Could use a better name.
Some goof in threading.
Tried to call non-existent method, that kind of thing.
Attempt to interact with external program failed (maybe it ran out of process slots, that kind of thing).
Duh.
Attempt to dereference wrong kind of thing.
Excessive subroutine recursion, maybe also infinite split or s///
loops (although arguably they would throw a Regex exception).
There are bound to be other categories that should be covered. This is just to put meat on the bones. This is the province of librarians; the fact that it's possible to argue endlessly about the choices doesn't preclude coming up with good ones.
This should not be construed as requiring that clearly fatal errors (e.g. pointer corrupted) should be trappable, or throw O-O exceptions. Note that compilation errors don't have to be classified.
RFC 70: Allow exception-based error-reporting.
RFC 85: All perl generated errors should have a unique identifier
RFC 88: Omnibus Structured Exception/Error Handling Mechanism
Error.pm (search.cpan.org).