March 3, 2026
Oops or Boom?
The Two Kinds of Error
Should apps say “oops” or just crash? The internet picks sides
TLDR: The article splits software errors into “expected” (handle gracefully) and “unexpected” (crash and fix the bug). The comments explode into a debate over exceptions vs. return values, fail-fast vs. fail-last, and whether validation mistakes are features—highlighting how error choices shape real user experience.
Software errors, the piece argues, come in two flavors: the expected kind (like a wrong password or bad Wi‑Fi) that should be handled kindly, and the unexpected kind (real bugs) that should be allowed to crash so they get noticed and fixed. Cue the comment section splitting into teams: Team “Let It Crash” vs. Team “Please Don’t Scare My Users.” One camp cheered the tough love—if it’s truly broken, blow it up. Another camp begged for nuance: not every hiccup is a disaster.
The spiciest thread? Exceptions vs. error results. One commenter said using built‑in tools like try/catch (which means “try something, and if it breaks, catch it safely”) is the clean way to handle many errors, while others insisted returning error results forces developers to plan for failure. Another hot take declared validation errors are basically a feature—users get guidance, not alarms. A pragmatic voice added a menu of strategies: fail‑fast (stop at the first error) vs. fail‑last (collect all mistakes and show them at once). Rust fans popped in to say not everything is “exceptional,” and someone shared a helpful link. Memes flew: “Space probe rules vs. weekend script energy,” and jokes about apps screaming “FATAL” when you typo your email. Drama, delivered.
Key Points
- •Errors are categorized into expected (normal operation) and unexpected (bugs).
- •Expected errors should be handled gracefully: return error results, use fallbacks, and log WARN/INFO.
- •Unexpected errors indicate bugs and can warrant crashing, with ERROR/FATAL logging.
- •The expected/unexpected boundary depends on application context, from prototypes to mission-critical systems.
- •Designing for reliability often means treating more conditions as expected and handling them.