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