Error Handling in Java and Python

Operational systems, by definition, need to work without human input. Systems are considered “operational” after they have been 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:

• No language statements for error handling
• tryCatch() is a function
• Need to define warning handler function
• Need to define error handling function
• Scope issues

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:

• Basic Error Handling with tryCatch()
• Exceptions and debugging - Advanced R

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.

• try() is a wrapper around tryCatch()
• try() ignores warnings
• try() returns a “try-error” object on error
• geterrmessage() returns latest error msg

For more details see:

• Easier Error Handling with try()

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:

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

library(MazamaCoreUtils)
logger.setup()
logger.setLevel(TRACE)

# Arbitrarily deep in the stack we might have:
myFunc <- function(x) {
  a <- log(x)
}

result <- try({
  
  userInput <- 10
  result <- try({
    logger.trace("class(userInput) = %s", class(userInput))
    myFunc(x=userInput)
  }, silent=TRUE)
  stopOnError(result)
  
}, silent = FALSE)
#> TRACE [2022-07-20 11:45:05] class(userInput) = numeric

# Continue despite any errors
  
result <- try({
  userInput <- "10"
  result <- try({
    logger.trace("class(userInput) = %s", class(userInput))
    myFunc(x=userInput)
  }, silent=TRUE)
  stopOnError(result)
}, silent = FALSE)
#> TRACE [2022-07-20 11:45:05] class(userInput) = character
#> ERROR [2022-07-20 11:45:05] Error in log(x) : non-numeric argument to mathematical function
#> Error : Error in log(x) : non-numeric argument to mathematical function

# Continue despite any errors

result <- try({
  result <- try({
    logger.trace("class(userInput) = %s", class(userInput))
    myFunc(x=userInput)
  }, silent=TRUE)
  stopOnError(result, "Unable to process user input")
}, silent = FALSE)
#> TRACE [2022-07-20 11:45:05] class(userInput) = character
#> ERROR [2022-07-20 11:45:05] Unable to process user input
#> Error : Unable to process user input

# Script completes with errors handled as they occurred