Designing for Failures

iteration

Designing for Failures

Failure flags and benign values

• Sometimes responding with a nil is good enough, i.e.

  def save
  # some failing code
  rescue
  nil
  end

• Related to this is the concept of "benign values"

The system might replace the erroneous value with a phony value that it knows to have a benign effect on the rest of the system

When the system's success doesn't depend on the outcome of the method in question, using a benign value may be the right choice. Benign values are also helpful in making the code more testable.

Example:

begin response = HTTP.get_response(url) JSON.parse(response.body) rescue Net::HTTPError { 'stock_quote' => '' } end 

• Instead of 'puts'ing, we can usewarn`

Warning as errors

Check out this hack:

module Kernel def warn(message) raise message end end warn 'uh oh' 

Remote failure reporting

• At OL we use Bugsnag
• Idea of bulkheads -> a wall beyond which failures cannot have an effect on other parts of the system
• you should put bulkheads between external services and processes

Circuit breaker pattern

Ending the program

• Calling exit ends the whole program
• Remember that time I used exit in the Whiz Tutor codebase?

Picks

John: User Onboard - https://www.useronboard.com/ by https://twitter.com/samuelhulick

JP: singlediv.com - https://twitter.com/samuelhulick