This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Merge C<$!>, C<$^E>, and C<$@>
=head1 VERSION
Maintainer: Peter Scott <[EMAIL PROTECTED]>
Date: 24 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 151
=head1 ABSTRACT
The distinction between the C<$!>, C<$^E>, 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"). When a C<die>
happens in an C<eval> block, aren't we overwriting a potentially useful
C<$!> by putting its output there? No, because the most common thing
people do with any C<$!> is C<die> with a message containing it, and then
only bother looking at C<$@> if they trap the C<die>.
What about the additional information available through C<$^E> on some
systems? If RFC 88 passes, C<$@> will become a structured exception
object; in a string context it evaluates to text; it could evaluate to an
errno-type code in a numeric context (although this author has never seen
any numeric use of C<$!> outside of documentation anyway), and for
additional, OS-dependent information, it could have a standardized
attribute named C<syserr> or whatever makes sense.
=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<$!> and C<@@> needs to be
changed to C<@!> in RFC 88.
=head2 C<$?>
While C<$?> is often discussed in the same breath as these other variables
(see L<perlvar"Error Indicators">, for example), this RFC does not consider
it part of the same solution space ("which of these things is not like the
others?"). I see no contradiction in leaving it the way it is.
=head1 REFERENCES
L<perlvar/"Error Indicators">
RFC 88: Structured Exception Handling Mechanism (Try)
RFC 80: Exception objects and classes for builtins
