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

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 <peter@psdt.com>
  Date: 25 Aug 2000
  Last Modified: 3 Oct 2000
  Mailing List: perl6-language-errors@perl.org
  Number: 151
  Version: 4
  Status: Frozen

=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 (assuming RFC 88 passes) 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.  In 
a numeric or string context, the variable will be the number that would 
currently be placed in C<$?>.  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.  The value of the variable in numeric and string contexts 
will be the same as what would currently be placed in C<$!>.  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

• RFC 151 (v4) Merge C<$!>, C<$^E>, C<$@> and C<$?> by Perl6 RFC Librarian