Decent error handling is important because:
src_compile
broke.
die
Function
The die
function should be used to indicate a fatal error and abort the
build. Its parameters should be the message to display.
Although die
will work with no parameters, a short message should always be
provided to ease error identification. This is especially important when a
function can die in multiple places.
Some portage-provided functions will automatically die upon failure. Others will
not. It is for example safe to omit the || die
after a call to epatch
,
but not emake
. The reason is that external binaries are not able to call
die that is a bash function. You can see what commands are external binaries
with ls /usr/lib*/portage/bin/ebuild-helpers
. In EAPI>=4 all ebuild-helpers automatically die upon failure.
Sometimes displaying additional error information beforehand can be useful. Use
eerror
to do this. See Messages.
It's best to use || die
too often than too little.
die
and Subshellsdie
will not work in a subshell.
The following code will not work as expected, since the die
is inside a
subshell:
[[ -f foorc ]] && ( update_foorc || die "Couldn't update foorc!" )
The correct way to rewrite this is to use an if
block:
if [[ -f foorc ]] ; then
update_foorc || die "Couldn't update foorc!"
fi
When using pipes, a subshell is introduced, so the following is unsafe:
cat list | while read file ; do epatch ${file} ; done
Using input redirection (see Abuse of cat) avoids this problem:
while read file ; do epatch ${file} ; done < list
assert
Function and $PIPESTATUS
When using pipes, simple conditionals and tests upon $?
will not correctly
detect errors occurring in anything except the final command in the chain. To get
around this, bash
provides the $PIPESTATUS
variable, and portage
provides the assert
function to check this variable.
bunzip2 "${DISTDIR}/${VIM_RUNTIME_SNAP}" | tar xf
assert
If you need the gory details of $PIPESTATUS
, see the bash manpage. Most of the
time, assert
is enough.