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