The author, an engineer at Amazon Web Services, reflects on a recent outage at Cloudflare and its implications for error handling in software systems. They highlight a key point from Cloudflare's postmortem: the use of Rust's Result struct, which can either return a successful result or trigger a crash if there's an error. This raises questions about the appropriateness of using assertions in production systems. The author argues that error handling isn't just a local decision; it's a global property of the entire system, affecting how components interact and manage failures. The article presents a series of scenarios involving server errors and asks readers to consider whether crashing the server is an appropriate response. The author outlines three principles for handling errors: the correlation of failures, whether errors can be managed at a higher architectural layer, and the feasibility of continuing operations after an error. They explain that in cases where failures are uncorrelated, crashing may simplify system management. However, in scenarios with potential correlated failures, systems should be designed to reject the cause of errors and continue functioning. Error handling strategies should be integrated into system design from the beginning. The author emphasizes the importance of blast radius reduction techniques, which limit the impact of errors to a smaller segment of traffic. This approach acknowledges the complexity of systems and aims to mitigate the consequences of failure. The discussion touches on Rust's features that improve error handling, like making the consequences of certain operations explicit, while also suggesting areas for improvement in Rust's handling of errors.