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 Last-Modified: 12 Aug 2000 Version: 2 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 syntax and semantics adapted from Graham Barr's Error.pm. This allows code like try { # fragile code } catch Exception::IO { # handle IO exceptions } catch Exception::Socket, Exception::FTP { # handle network exceptions } catch { # 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. Builtins experiencing fatal errors currently call C<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 C<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. 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 Object Attributes The exception object will have these attribute methods filled in by perl: =over 4 =item id Unique numeric identifier, assigned by perl developers. A number range for user exceptions will also need to be provided. I am not going to touch the issue of whether the perl developers should set up registries for CPAN developers to grab ranges for their own exceptions. =item message The text of the exception, e.g., "Out of memory". =item severity Relative level of fatality. Chosen from some TBD enumeration. =item line Line number exception was thrown at. =item file File exception was thrown in. =item data[(userdata)] User data, arbitrarily complex. If the user knew the underlying object implementation, of course they could stick in attributes with any names they wanted; but nothing should rely on that, so this hook is provided. =back Stringifying the object itself will yield the C<message> attribute. A C<facility> attribute was suggested to indicate what part of perl is throwing the exception: IMO that is covered in the exception class. =head2 Classes 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 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 subdividing. =item Regex A syntax error occurred in a regex (built at run-time). Possible candidate for subdivision. =item IO An I/O error occurred. Almost certainly should be subdivided, 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; 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: Exception handling syntax proposal. RFC 70: Allow exception-based error-reporting. RFC 85: All perl generated errors should have a unique identifier RFC 88: Structured Exception Handling Mechanism (Try) Error.pm (C<http://search.cpan.org/doc/GBARR/Error-0.13/Error.pm>). L<perldiag>.
