To see what is currently happening visit http://www.perl6.org/
Merge $!, $^E, $@ and $?
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
The distinction between the $!, $^E, $@ and $? variables is no
longer worth trading for the benefits to be gained from merging them together.
The $! variable made excellent sense in Perl 4 as a representation of
the Unix C RTL 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 $! is set and those it isn't, less useful.
Non-system code throws exceptions by dieing and any code that handles
those exceptions reads the reasons in the $@ 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 open but not, say, for a failed 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 eval.
Merge all these variables into one. Say for the sake of argument that it
is $! (for the mnemonic value of "something went bang"). This variable
will always be an object. An attribute will determine whether it is
something that can be caught or could cause a die; this will be checked
by code implementing exception handling (like, say, RFC 88). Call this
attribute 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 Fatal.pm applicable throughout the core
and optionally to user modules.
Note that if RFC 88 passes, it requires $@ 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 $^E is just an extension of
$!, so we can consider those two variables collapsed into $!. 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 catch and
finally blocks (see RFC 88). It cannot occur in a try block because
as soon as anything would create an exception, it will cause control to
leave the try block.
In a 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 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 finally
block and restore it on exit. The one remaining issue is how the user can
access the current exception in a catch or finally block after a
non-exception error. In this arguably rare case, they could get it from
the first element of the
@@ array, which RFC 88 defines as the exception stack.
To expand upon parts of the above table:
After a failed system, `` or anything else that currently sets $?:
the variable will be created with the is_exception attribute false. In
a numeric or string context, the variable will be the number that would
currently be placed in $?. If the variable already existed, then if
is_exception was false, it is overwritten, otherwise see the discussion
above.
On a failed system call (something that currently sets $!; not a
system call): the variable will be created with the 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 $!. Where the
$^E variable would currently be set, set a extra_info attribute or
some such. (We could actually use the 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
is_exception was false, it is overwritten, otherwise see the discussion
above.
On a throw or die: the variable will be created with the
is_exception attribute true. If the variable previously existed with a
is_exception value of false, a link to the previous value will be
provided in the sysmsg attribute. RFC 88 details how and under what
circumstances the variable is linked to a previous version which had
is_exception true.
If the variable chosen is $@, no impact. If the variable chosen is
$!, then $@ needs to be changed to $!. The implementation of RFC
88 will need to check not merely for the existence of the error variable
but whether its is_exception attribute is set to know whether there is a
current exception.
RFC 88: Structured Exception Handling Mechanism (Try)
RFC 80: Exception objects and classes for builtins
RFC 70: Allow exception-based error reporting