This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Merge C<$!>, C<$^E>, C<$@> and C<$?>
=head1 VERSION
Maintainer: Peter Scott <[EMAIL PROTECTED]>
Date: 25 Aug 2000
Last-modified: 5 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 2
Number: 151
Status: Developing
=head1 ABSTRACT
The distinction between the C<$!>, C<$^E>, C<$@> and C<$?> variables is no
longer
worth trading for the benefits to be gained from merging them together.
=head1 DESCRIPTION
The C<$!> variable made excellent sense in Perl 4 as a representation of
the Unix C RTL C<errno>. It went right along with the tight integration
and close mapping between Perl and sections 2 and 3 of the Unix manual.
The amount of third-party code published via CPAN made possible by the
module features of Perl 5, and the likelihood of exception handling gaining
increased importance in Perl 6 both serve to make the distinction between
errors for which C<$!> is set and those it isn't, less useful.
Non-system code throws exceptions by C<die>ing and any code that handles
those exceptions reads the reasons in the C<$@> variable. Why have two
classes of errors where failure reasons are passed in different variables
when the distinction between those classes may appear irrelevant (not a
Unix platform) or arbitrary (what is a "system error" and why should it be
set for a failed C<open> but not, say, for a failed C<new IO::Socket>?)?
Hence this proposal is to merge all these together into a single
out-of-band indicator of error, so that users don't have to check multiple
variables in the case of an C<eval>.
=head1 IMPLEMENTATION
Merge all these variables into one. Say for the sake of argument that it
is C<$!> (for the mnemonic value of "something went bang"). This variable
will I<always> be an object. An attribute will determine whether it is
something that can be caught or could cause a C<die>; this will be checked
by code implementing exception handling (like, say, RFC 88). Call this
attribute C<is_exception> for the sake of argument.
It should be possible to make the same attribute fulfil and extend the
requirement of RFC 70 to make C<Fatal.pm> applicable throughout the core
and optionally to user modules.
Note that if RFC 88 passes, it requires C<$@> to become a structured object
anyway; this RFC simply proposes using the same object for other errors as
well.
What about situations where more than one of the current set of four variables
might be set? Well, note that C<$^E> is just an extension of C<$!>, so we can
consider those two variables collapsed into C<$!>. The following cases obtain:
Perl would | The error variable is currently
currently set |Non-existent: |Existent, and is_exception is
|create new one| true | false
|setting its | |
|is_exception | |
==============|==============|==============|===============
$!, $^E | Depends on | Overwrite, |
| Fatal.pm | but see |
| applicability| discussion | Overwrite
--------------+--------------+ below +
$? | False | |
--------------+--------------+--------------+---------------
$@ | True | New one links| New one links
| | to previous | to previous
| | per RFC 88 | via sysmsg
The one case that needs special attention is when the variable is holding a
current exception and a non-exception error occurs. Furthermore, the only
place this is a problem is C<catch> and C<finally> blocks (see RFC 88). It
cannot occur in a C<try> block because as soon as anything would create an
exception, it will cause control to leave the C<try> block.
In a C<catch> block, the exception is to be cleared at the end of the block
anyway so overwriting it with a non-exception error would not cause a problem
for control flow. In a C<finally> block, any current exception needs to be
preserved at the end of the block, therefore it cannot be overwritten; but
Perl could save the exception on entry to the C<finally> block and restore
it on exit. The one remaining issue is how the user can access the current
exception in a C<catch> or C<finally> block after a non-exception error. In
this arguably rare case, they could get it from the first element of the
C<@@> array, which RFC 88 defines as the exception stack.
To expand upon parts of the above table:
After a failed C<system>, C<``> or anything else that currently sets C<$?>:
the variable will be created with the C<is_exception> attribute false. If
the variable already existed, then if C<is_exception> was false, it is
overwritten, otherwise see the discussion above.
On a failed system call (something that currently sets C<$!>; not a C<system>
call): the variable will be created with the C<is_exception> attribute false.
Where the C<$^E> variable would currently be set, set a C<extra_info>
attribute
or some such. (We could actually use the C<sysmsg> attribute, but that might
confuse people traversing linked errors who expect that always to be a
reference or undef.) If the variable already existed, then if C<is_exception>
was false, it is overwritten, otherwise see the discussion above.
On a C<throw> or C<die>: the variable will be created with the C<is_exception>
attribute true. If the variable previously existed with a C<is_exception>
value of false, a link to the previous value will be provided in the C<sysmsg>
attribute. RFC 88 details how and under what circumstances the variable is
linked to a previous version which had C<is_exception> true.
=head2 Impact on RFC 88
If the variable chosen is C<$@>, no impact. If the variable chosen is
C<$!>, then C<$@> needs to be changed to C<$!>. The implementation of
RFC 88 will need to check not merely for the existence of the error
variable but whether its C<is_exception> attribute is set to know whether
there is a current exception.
=head1 REFERENCES
L<perlvar/"Error Indicators">
RFC 88: Structured Exception Handling Mechanism (Try)
RFC 80: Exception objects and classes for builtins
RFC 70: Allow exception-based error reporting
