Error Handling

Jonathan Callahan

2018-12-02

Error Handling in Java and Python

Operational systems, by definition, need to work without human input. Systems are considered “operational” after they have ben thoroughly tested and shown to work properly with a variety of input.

However, no software is perfect and no real-world system operates with 100% availability or 100% consistent input. Things occasionally go wrong – perhaps intermittently. In a situation with occasional failures it is vitally important to have robust error handling to deal with both expected and unexpected results.

Other languages used in operational settings have language statements to help with error handling. The code to handle errors looks very similar in java and python:

java

try {
  myFunc(a)
} catch (abcException e) {
  // handle abcException
} catch (defException e) {
  // handle defException
} finally {
  // always executed after handlers
}

python

try:
  myFunc(a)
except abcError:
  # handle abcError
except defError:
  # handle defError
finally:
  # always executed after handlers

Error Handling in R

Not surprisingly, a functional language like R does things differently:

Nevertheless, R’s error handling functions can be made to look similar to java and python:

result <- tryCatch({
  myFunc(a)
}, warning = function(w) {
  # handle all warnings
}, error = function(e) {
  # handle all errors
}, finally = {
  # always executed after handlers
}

For more details see:

Simpler Error Handling in R

In our experience, R’s error handling is too complicated for simple use and requires too much from folks who don’t consider themselves R-gurus.

Instead, we recommend wrapping any block of code that needs error handling in a try() function and then testing the result to see if an error occurred.

For more details see:

This strategy makes it easy to create error handling logic and easy to understand what it does. In the following pseudo-code please note that R considers everything between {} to be a single expression:

result <- try({
  # ...
  # lines of R code
  # ...
}, silent = TRUE)

if ( "try-error" %in% class(result) ) {
err_msg <- geterrmessage()
  # logging of error message
  # detection and handling of particular error strings
  # stop() if necessary with user friendly error strings
}

Regularized Usage in Operational Code

The following utility function regularizes our handling of errors in operational code:

stopOnError()

This function tests the first argument for a class of try-error and, if true, performs the following actions:

  1. creates err_msg from a user provided error message or, if NULL, geterrmessage()
  2. logs this message with logger.error(err_msg)
  3. throws the potentially improved error message with stop(err_msg)

Encouraging junior R programmers to add error handling to their code is now much easier. They can place any block of R code within a “try block” with the following minimal syntax:

result <- try({
  # ...
  # lines of R code
  # ...
}, silent = FALSE)
stopOnError(result)

Here is a working example demonstrating how a web service might test for user input that may not have been converted from character to numeric: