RFC 151 (v1) Merge C<$!>, C<$^E>, and C<$@>

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