The Do's and Don'ts of Error Handling
summary
Argues that fault tolerance requires multiple machines, asynchronous message passing and let it crash supervision trees that detect failures and restart processes (restarts happen in sub‑microsecond time scales). Recommends six core properties: concurrency, error encapsulation, fault detection, identification, live code change and stable storage; isolates an error kernel of roughly 200 lines that logs faults and restarts children. Cites Erlang/OTP usage in Ericsson, WhatsApp, RabbitMQ and CouchDB and urges protocol contracts/session types to assign blame across networked components.
AI-written summary · about
chapters (24)
- 0:00Introduction
- 2:13Fault tolerance cannot be achieved by a single computer
- 8:36Communicating sequential processes
- 14:02A timeline of Joes involvement
- 18:32Types of systems
- 21:32Rules
- 24:07Smart Data
- 24:52What is an Error
- 25:27What to do when the Runtime finds an Error
- 27:32Programming Languages
- 28:22Parallel Programs
- 29:32Concurrent
- 30:12Security
- 31:57Concurrency
- 32:52Detecting Errors
- 33:12Arithmetic
- 33:37Silent Programming
- 36:07Arithmetic is Difficult
- 36:27A Quiz
- 37:02Let It Crash
- 37:47The Message
- 38:02Observational Equivalents
- 39:07Session Types
- 39:57Protocols
related talks
55mGoing Resilient
36mDesigning for failure - architecting fault-tolerant system
53mIdioms for Building Distributed Fault-tolerant Applications with Elixir
44mAfter The Crash
31mHow does fault tolerance work in Erlang
57mReliability Nirvana
41mIdioms for building fault-tolerant applications with Elixir
01h 12mRedundancy does not imply fault tolerance