Peter Scott wrote:
> >Maybe $! becomes an alias for anything that gets thrown
>
> Actually it looks like $@ is doing that at the moment. *Confused*
Make them all writable, then we can make user-defined errors seem
to be whatever we want.
Or leave them the hell alone and introduce a new variable $^t which
will be "whatever got thrown last" instead of bothering with
propagating it around within the handlers.
Just to be even more confusing.
Anyway here are the current documentations, to unconfuse you and
anyone else who needs to see this:
Error Indicators
The variables $@, $!, $^E, and $? contain information about different types of error
conditions that may appear during
execution of
Perl script. The variables are shown ordered by the ``distance'' between the subsystem
which reported the error and the
Perl process,
and correspond to errors detected by the Perl interpreter, C library, operating
system, or an external program,
respectively.
To illustrate the differences between these variables, consider the following Perl
expression:
eval '
open PIPE, "/cdrom/install |";
@res = <PIPE>;
close PIPE or die "bad pipe: $?, $!";
';
After execution of this statement all 4 variables may have been set.
$@ is set if the string to be eval-ed did not compile (this may happen if open or
close were imported with bad
prototypes), or if Perl
code executed during evaluation die()d (either implicitly, say, if open was imported
from module the Fatal manpage, or
the die after
close was triggered). In these cases the value of $@ is the compile error, or Fatal
error (which will interpolate $!!),
or the argument
to die (which will interpolate $! and $?!).
When the above expression is executed, open(), <PIPE>, and close are translated to C
run-time library calls. $! is set
if one of these
calls fails. The value is a symbolic indicator chosen by the C run-time library, say
No such file or directory.
On some systems the above C library calls are further translated to calls to the
kernel. The kernel may have set more
verbose error
indicator that one of the handful of standard C errors. In such cases $^E contains
this verbose error indicator, which
may be, say,
CDROM tray not closed. On systems where C library calls are identical to system calls
$^E is a duplicate of $!.
Finally, $? may be set to non-0 value if the external program /cdrom/install fails.
Upper bits of the particular value
may reflect
specific error conditions encountered by this program (this is program-dependent),
lower-bits reflect mode of failure
(segfault,
completion, etc.). Note that in contrast to $@, $!, and $^E, which are set only if
error condition is detected, the
variable $? is set on each
wait or pipe close, overwriting the old value.
For more details, see the individual descriptions at $@, $!, $^E, and $?.
$EVAL_ERROR
$@
The Perl syntax error message from the last eval() command. If null, the last
eval() parsed and executed correctly
(although
the operations you invoked may have failed in the normal fashion). (Mnemonic:
Where was the syntax error ``at''?)
Note that warning messages are not collected in this variable. You can, however,
set up a routine to process
warnings by setting
$SIG{__WARN__} as described below.
$OS_ERROR
$ERRNO
$!
If used in a numeric context, yields the current value of errno, with all the
usual caveats. (This means that you
shouldn't
depend on the value of $! to be anything in particular unless you've gotten a
specific error return indicating a
system error.) If
used in a string context, yields the corresponding system error string. You can
assign to $! to set errno if, for
instance, you
want "$!" to return the string for error n, or you want to set the exit value for
the die() operator. (Mnemonic:
What just went
bang?)
$EXTENDED_OS_ERROR
$^E
Error information specific to the current operating system. At the moment, this
differs from $! under only VMS,
OS/2, and Win32
(and for MacPerl). On all other platforms, $^E is always just the same as $!.
Under VMS, $^E provides the VMS status value from the last system error. This is
more specific information about
the last
system error than that provided by $!. This is particularly important when $! is
set to EVMSERR.
Under OS/2, $^E is set to the error code of the last call to OS/2 API either via
CRT, or directly from perl.
Under Win32, $^E always returns the last error information reported by the Win32
call GetLastError() which
describes the
last error from within the Win32 API. Most Win32-specific code will report errors
via $^E. ANSI C and UNIX-like
calls set errno
and so most portable Perl code will report errors via $!.
Caveats mentioned in the description of $! generally apply to $^E, also.
(Mnemonic: Extra error explanation.)
$CHILD_ERROR
$?
The status returned by the last pipe close, backtick (``) command, or system()
operator. Note that this is the
status word
returned by the wait() system call (or else is made up to look like it). Thus,
the exit value of the subprocess is
actually ( $?
>> 8), and $? & 127 gives which signal, if any, the process died from, and $? &
128 reports whether there was a
core dump.
(Mnemonic: similar to sh and ksh.)
Additionally, if the h_errno variable is supported in C, its value is returned
via $? if any of the gethost*()
functions fail.
Note that if you have installed a signal handler for SIGCHLD, the value of $?
will usually be wrong outside that
handler.
Inside an END subroutine $? contains the value that is going to be given to
exit(). You can modify $? in an END
subroutine to
change the exit status of the script.
Under VMS, the pragma use vmsish 'status' makes $? reflect the actual VMS exit
status, instead of the default
emulation of
POSIX status.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
Damian Conway for president
