iteration

Designing for Failures

Episode Summary

This week we talk about failure flags and benign values, report failure reporting, and warning as errors.

Episode Notes

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