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
