[% setvar title Exception objects and classes for builtins %]

This file is part of the Perl 6 Archive

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.

Object Attributes

The exception object will have attributes filled in by perl. The applicable attributes from RFC 88 will be used, including:

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.

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).