This module contains some error printing routines taken
from Advanced Programming in the UNIX Environment
by W. Richard Stevens.
These functions are all called in the same manner as
printf(), i.e. with a string containing format specifiers
followed by a list of corresponding arguments. All output from
these functions is to stderr.
The message provided by the caller is printed. This
function is simply a wrapper for fprintf().
Use this function when a fatal error has occurred that
is not due to a system call. The message provided by the
caller is printed and the process terminates with an exit
value of 1. The function does not return.
Use this function after a failed system call. The message
provided by the caller is printed followed by a string
describing the reason for failure.
Use this function after a failed system call. The message
provided by the caller is printed followed by a string
describing the reason for failure, and the process
terminates with an exit value of 1. The function does not
return.
Most functions in erl_interface report failures to the caller by
returning some otherwise meaningless value (typically NULL
or a negative number). As this only tells you that things did not
go well, you will have to examine the error code in
erl_errno if you want to find out more about the failure.
erl_errno is initially (at program startup) zero and
is then set by many erl_interface functions on failure to a
non-zero error code to indicate what kind of error it
encountered. A successful function call might change
erl_errno (by calling some other function that
fails), but no function will ever set it to zero. This means
that you cannot use erl_errno to see if a
function call failed. Instead, each function reports failure
in its own way (usually by returning a negative number or
NULL), in which case you can examine erl_errno
for details.
erl_errno uses the error codes defined in your
system's <errno.h>.
Note
Actually, erl_errno is a "modifiable lvalue" (just
like ISO C defines errno to be) rather than a
variable. This means it might be implemented as a macro
(expanding to, e.g., *_erl_errno()). For reasons of
thread- (or task-)safety, this is exactly what we do on most
platforms.