| Note: these documents may be out of date. Do not use as reference! |
To see what is currently happening visit http://www.perl6.org/
Allow exception-based error-reporting.
Maintainer: Bennett Todd <bet@rahul.net> Date: 8 Aug 2000 Last Modified: 18 Sep 2000 Mailing List: perl6-language@perl.org Number: 70 Version: 4 Status: Frozen
1. Status frozen. 2. Added NOTES ON FREEZE section. 3. Dropped glob from the list of non-wrappable builtins.
Allow full implementation of Fatal.pm, for programmers who prefer exceptions for error reporting. To enable this, ensure that all builtins (like e.g. print()) that return errors can be wrapped. In addition, ensure that builtins like e.g. integer division, which currently throw exceptions on errors, can have that behavior switched off. At least print, and printf should be wrappable.
Perl has traditionally reflected the Unix syscall and library tradition for error reporting: errors are indicated by otherwise-impossible return values, which must be checked for explicitly, lest system error events be ignored. Some programmers prefer to have errors print a message and exit with non-zero status, by default, rather than having to always code " || die ...". In perl5 this has proven elusive of implementation.
Fatal.pm has been the attempt made to date, and it suffers from two problems. One can be fixed with further development: it should have various lists of builtins available, e.g. :io, :system, :all for including all calls affecting I/O, all system calls of any sort, and all calls that can have error returns. If these were a success, then the requested category could also be posted into a testable variable, allowing module authors who wished to to automatically support this functionality as well.
In addition, for classes of errors that currently throw exceptions, Fatal could be taught to disable them, allowing e.g.
no Fatal qw(:arithmetic); my $result = 1 / 0; # $result now contains undef, w/ # error posted in $! or maybe $@
But Fatal.pm development stalls out early, because some builtins, which report testable error conditions, cannot be wrapped. A conspicuous example is print().
Ensure that every perl builtin that can return an error, can be wrapped. Perhaps in addition ensure that routines that currently die on error, can have their behavior changed as well.
For the first part, tchrist posted a nice list of non-overridable builtins; running my eye down it, it looks like the gross offenders here are:
print, printf
I don't know whether this is purely an implementation issue (and so lies solely in the domain of perl6-internals) or whether any programmer-visible changes may be necessary to allow this (justifying posting to perl6-language).
This RFC drew very little discussion. It simply proposes a fix to the core, allowing a couple of existing routines to be wrapped, which would allow the completion of an already-existing external module to allow exception-style error handling. Other RFCs have gone far further in requesting that exceptions and/or objects representing them be welded into the core. The changes during its life were additions of references, just below, and specifics about the currently-unwrappable core routines that can return errors, deduced from a list posted by tchrist.
Fatal.pm, as included with recent perls.
Error.pm, available from CPAN, and cited by RFC 63: if this proposal should carry, then Fatal.pm will see some very active development, and if RFC 63 should also prevail, then Fatal's development should be guided by RFC 63/Error.pm.
RFC 80 Proposes a taxonomy for exception objects; should it prevail, it should guide the structure of exceptions thrown when Fatal.pm gets worked on.