Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

If a program does not sanity check its operations and data, it can sometimes proceed for many subsequent steps until finally either a bad (or empty) result is generated, or some called program that does sanity check its data notices and terminates execution. It is then challenging to backtrack to where the original, causative error occurred – assuming there are even log files available to examine!

Some languages (Python, Java, R) automatically detect certain types of errors (e.g. file not found) and, by default, stop program execution and report an execution stack trace that can be displayed to the user. While these stack traces are not usually meaningful on their own, they are better than nothing, and certainly better than allowing the program to blithely continue.

But built-in error runtime error checks are no help in sanity checking program data, because only the programmer knows what the data should look like! Enter user-defined error checking. Again, some languages make this less cumbersome:

  • Python assert statement
  • Java assert keyword
  • R stopifnot statement

These languages also have throw/catch exception handling constructs, which lets a program detect and deal with errors – if possible.

...

  • To stop execution immediately when an error is detected
  • Have the last line of the log file describe the fatal error (easy to tail)
  • Make it easy to frequently check for errors of different sorts in our code
  • Report the check being done (even when successful) in order to leave "bread crumbs" in the log file for troubleshooting.
  • Report all diagnostics to standard error so it will not interfere with a function's standard output that is meant to be captured by the caller
    • This way, So if a function reports error checks to standard error, and also reports information on standard output, only the standard output will be captured by backtick or parentheses evaluation.

...

The main error function is just called err, and is called with some descriptive text elsewhere when an error is detected. It outputs that text with some surrounding decoration, and exits with a non-0 error code.

If we do our error checking properly, and an error occurs, this the text from err will be the last line in the log file. Or the text "...exiting" can also be grep'd for in the log file to see if something bad happened.

...

The check_res function checks the result/exit code passed in to it (usually our friend $?).

Note that here and in other error checking fuctionsfunctions, maybe_echo is used for diagnostic messages, so that they can be suppressed via the ECHO_VERBOSE environment variable, while text describing real errors is always displayed.

Code Block
languagebash
# Function to check result code of programs.
# Exits with a standard error message if code is non-zero.
# Otherwise displays a completion message.
#   arg 1 - the return code (usually $?)
#   arg 2 - text describing what ran (optional)
check_res() {
  if [[ "$1" == "0" ]]; then maybe_echo ".. check_res: $2 OK";
  else err "$2 returned non-0 exit code $1"; fi
}

...