# What Now? Handling Errors in Large Systems

DevFeed: [What Now? Handling Errors in Large Systems](<https://devfeed.tech/articles/what-now-handling-errors-in-large-systems-12583.md>)

Original publisher: [Read original article](<http://brooker.co.za/blog/2025/11/20/what-now.html>)

Author: Marc Brooker

Published: 2025-11-20T00:00:00Z

Content type: article

Language: en

Sources: [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog.md>), [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog-2.md>)

Topics: [systems](<https://devfeed.tech/topics/systems.md>), [Resilience](<https://devfeed.tech/topics/resilience.md>), [Rust](<https://devfeed.tech/topics/rust.md>), [Processes](<https://devfeed.tech/topics/processes.md>), [autoscaling](<https://devfeed.tech/topics/autoscaling.md>), [Amazon Web Services](<https://devfeed.tech/topics/aws.md>), [Serverless](<https://devfeed.tech/topics/serverless.md>), [Erlang](<https://devfeed.tech/topics/erlang.md>), [Containers](<https://devfeed.tech/topics/containers.md>), [servers](<https://devfeed.tech/topics/servers.md>)

Tags: [architecture](<https://devfeed.tech/tags/architecture.md>), [autoscaling](<https://devfeed.tech/tags/autoscaling.md>), [aws](<https://devfeed.tech/tags/aws.md>), [component](<https://devfeed.tech/tags/component.md>), [errors](<https://devfeed.tech/tags/errors.md>), [http](<https://devfeed.tech/tags/http.md>), [outage](<https://devfeed.tech/tags/outage.md>), [process](<https://devfeed.tech/tags/process.md>), [resilience](<https://devfeed.tech/tags/resilience.md>), [rust](<https://devfeed.tech/tags/rust.md>), [server](<https://devfeed.tech/tags/server.md>), [serverless](<https://devfeed.tech/tags/serverless.md>), [servers](<https://devfeed.tech/tags/servers.md>), [systems](<https://devfeed.tech/tags/systems.md>)

## AI overview

An analysis of error handling in large systems, using Rust's Result and unwrap as a starting point. It argues that whether a component should crash is a system-wide architectural decision shaped by failure correlation, error-handling layers, business logic, and the value of continuing with a last-known-good configuration or data version.

## Source excerpt

What Now? Handling Errors in Large Systems More options means more choices. Cloudflare's deep postmortem for their November 18 outage triggered a ton of online chatter about error handling, caused by a single line in the postmortem: .unwrap() If you're not familiar with Rust, you need to know about Result, a kind of struct that can contain either a successful result, or an error. unwrap says basically "return the successful results if there is one, otherwise crash the program"1. You can think of it like an assert. There's a ton of debate about whether asserts are good in production2, but most are missing the point. Quite simply, this isn't a question about a single program. It's not a local property. Whether asserts are appropriate for a given component is a global property of the system, and the way it handles data. Let's play a little error handling game. Click the ✅ if you think crashing the process or server is appropriate, and the ❌ if you don't. Then you'll see my vote and justification. One of ten web servers behind a load balancer encounters uncorrectable memory errors, and takes itself out of service. ✅ ❌ Your vote: My vote: ✅ Uncorrectable memory errors are independent, and do not depend on user-provided content. In the presence of bad memory, it's impossible for a program to proceed safely. Taking the machine out of service is the safest course of action. One of ten multi-threaded application servers behind a load balancer encounters a null pointer in business logic while processing a customer request. ✅ ❌ Your vote: My vote: ❌ Customer requests triggering bugs in business logic isn't a good reason to bring the whole server down. Instead, fail that particular request (returning an HTTP 5xx error), and continue with other user requests. In approaches like Erlang, or even Lambda, it may be the right approach to crash the whole application in response to a bad request, because this crash is handled at a higher layer in the architecture. This is also why I pr