When to give up, and how?
summary
Programs that silently mask bugs cause worse failures than crashing; corrupting user data is the real horror. Use assertions and contracts where possible, and when a component is inconsistent terminate early, gather actionable info. On Unix, fork and abort to get a core dump while the parent keeps running to limit damage. Keep small in-memory RAM state-machine logs so postmortem reproductions and unit tests are trivial. Prefer simple, architectural fault tolerance and a separate monitor that collects logs and cores for developers.
AI-written summary · about
chapters (15)
- 0:00Introduction
- 1:09Data corruption experience
- 4:21Bugs versus disappointments
- 6:53Program bug detection
- 10:52Counterbugs problem
- 12:40Asserts for early exit
- 15:11Contract programming in C++
- 18:49Crashes improving stability
- 22:47Fault tolerance in AXE exchange
- 28:50Architectural fault tolerance
- 31:39Unix fork and core dumps
- 33:29RAM logs and postmortem debugging
- 36:43Bug handling strategies
- 38:27Cost of clever resilience
- 40:16Q&A
related talks
49mDebugging with the Scientific Method
01h 09mPlenary: Coping With Other People's C++ Code
08mTalk to me! The art of reporting a bug (and handling the feedback)
26mCommunication: What are you Thinking About?
54mSeeing Like a Programmer - Resiliency, Limits, And Moral Hazards In SE
17mIf You’re Happy and You Know It (Inside the Mind of a Developer)
22mHow to be an inefficient developer?
32mLife As A Developer: My Code Does Not Work Because I Am A Victim Of Complex Societal Factors...