This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Exception objects and classes for builtins =head1 VERSION Maintainer: Peter Scott <[EMAIL PROTECTED]> Date: 9 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 80 =head1 ABSTRACT 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). =head1 DESCRIPTION RFC 63 proposes a standard exception handling mechanism with the syntax and semantics of Graham Barr's Error.pm. This allows code like try { # fragile code } catch Exception::IO with { # handle IO exceptions } catch Exception::Socket with { # handle network exceptions } otherwise { # handle other exceptions }; Exceptions are objects blessed into classes the user names after the type of exception; their attributes include text which will be be given to C<die> (one that won't be trapped) if the exception is uncaught. So modules can throw exceptions without requiring that the user be trapping them. RFC 70 proposes that all builtins throw trappable exceptions on error. This RFC proposes that those exceptions be objects blessed into a standard set of classes which can be checked for by the user. This is much cleaner than eval { # fragile code }; if ($@) { # play guessing games with regexen on $@ # and hope that the error message doesn't # change in the next release. } Yes, this proposal is very Javaish. I don't do much programming in Java but I like the way it does this. =head2 Classes This is a strawman exception class hierarchy. The merits of this RFC do not depend on this beign a good hierarchy, only on it being possible to find a reasonable one. A common prefix like C<Exception::> is elided for readability. =over 4 =item Arithmetic Divide by zero and friends. =item Memory C<malloc> failed, request too large, that sort of thing. =item Eval A compilation error occurred in C<eval>, C</e>, or C<(?{ ... })>. Possible candidate for subclassing. =item Regex A syntax error occurred in a regex (built at run-time). Possible candidate for subclassing. =item IO An I/O error occurred. Almost certainly should be subclassed, perhaps parallel to the C<IO::> hierarchy. =item Format Error in format given to C<pack>, C<printf>, octal/hex/binary number etc. Could use a better name. =item Thread Some goof in threading. =item Object Tried to call non-existent method, that kind of thing. =item System Attempt to interact with external program failed (maybe it ran out of process slots, that kind of thing). =item Taint Duh. =item Reference Attempt to dereference wrong kind of thing. =item Recursion Excessive subroutine recursion, maybe also infinite C<split> or C<s///> loops (although arguably they would throw a C<Regex> exception). =back 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 and taxonomists; the fact that it's possible to argue endlessly about the choices doesn't preclude coming up with good ones. =head1 IMPLEMENTATION 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. Do we need to mention the C<$SIG{__DIE__} problem again? =head1 REFERENCES RFC 63, RFC 70, C<http://search.cpan.org/doc/GBARR/Error-0.13/Error.pm>, L<perldiag>.
