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 (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, 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 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 attribute. A
C 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 is elided for
readability.
=over 4
=item Arithmetic
Divide by zero and friends.
=item Memory
C failed, request too large, that sort of thing.
=item Eval
A compilation error occurred in C, C, 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 hierarchy.
=item Format
Error in format given to C, C, 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 or C
loops (although arguably they would throw a C 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
