Iteration Podcast
Designing for Failures
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 use
warn`
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