Errors, edge cases & defensive programming
Key takeaways Errors are normal — design for them, don’t bolt them on. Validate at boundaries — distrust input from the outside world. Fail fast or soft deliberately — crash on bugs, degrade gracefully on expected trouble.
A program that only works when everything goes right barely works at all. Real systems run in a hostile world: networks drop, disks fill, users mistype, and — for software like GopherTrunk — radio signals arrive smeared with noise and dropped samples. The defining trait of professional code isn’t that it handles the happy path; it’s that it handles everything else with composure. This lesson is about robustness: treating errors as normal, validating what you can’t trust, and choosing deliberately how to respond when things go wrong.
Errors are normal, not exceptional
The biggest mindset shift is to stop thinking of errors as rare anomalies. A file not existing, a connection timing out, a malformed message — these are routine. If error handling feels like an annoying afterthought, your design is fighting reality.
Robust code treats the error path as a first-class part of the design, considered alongside the success path from the start. The question for every operation that touches the outside world is not “what if this fails?” but “when this fails, what should happen?” Asking it early leads to clear, deliberate handling; asking it never leads to crashes and silent corruption.
Styles of error handling
Languages take different approaches to representing and propagating errors. Knowing the trade-offs helps you write robust code in any of them.
- Exceptions (Java, Python, C#) — errors are thrown and unwind the stack until something catches them. Convenient, but easy to ignore: an uncaught exception can crash the program, and it’s not obvious from a function’s signature what it might throw.
- Explicit error returns (Go) — functions return an error value alongside their result, and the caller must decide what to do. Verbose, but the error path is impossible to overlook because it’s right there in the code.
- Result / Option types (Rust’s
Result, many functional languages) — errors are part of the return type, and the compiler forces you to handle both the success and failure cases before you can use the value.
// Go makes the error path explicit and unavoidable.
frame, err := decoder.Decode(raw)
if err != nil {
return fmt.Errorf("decoding frame: %w", err) // wrap with context, propagate
}
// only reach here on success
use(frame)
There’s no universally “best” style, but the modern lean is toward explicit handling (returns or Result types) over invisible exceptions, precisely because errors are normal and should be visible. Whatever the style, the anti-pattern is the same: swallowing an error silently — an empty catch {} or ignoring a returned error — which turns a recoverable problem into a mysterious one later.
Validate inputs at the boundaries
A robust system distrusts data crossing into it from the outside: user input, network payloads, file contents, hardware feeds. Validate at the boundary — the moment data enters your system — so that the interior code can assume it’s working with well-formed values.
This concentrates messy, defensive checks at the edges and keeps the core clean. Inside the boundary, you’ve already established invariants (the frame length is valid, the field is non-negative), so deep internal code doesn’t need to re-check everything. Pushing validation to the edges is both safer and tidier than scattering paranoid checks everywhere.
A related idea is fail fast: when an input violates an invariant, reject it immediately and loudly rather than letting a bad value slip deeper, where it’ll cause a confusing failure far from the cause. The closer an error is reported to its origin, the easier it is to diagnose.
Defensive programming — without paranoia
Defensive programming means writing code that anticipates misuse and bad data. Done well, it makes systems resilient. Done blindly, it bloats code with redundant checks and hides real bugs.
Useful defensive habits:
- Check assumptions at boundaries, then trust them internally.
- Use assertions or guard clauses to catch programmer errors early during development.
- Handle the edge cases: empty inputs, zero, negative numbers, maximum values, off-by-one limits, concurrent access. Most bugs live at the edges, not the middle.
- Make illegal states unrepresentable where the type system allows — a value that can’t be constructed wrong can’t be wrong.
The balance: defend against the things that can genuinely happen (external input, hardware faults, concurrency), but don’t wrap every internal call in needless checks. Excessive defensiveness can mask bugs — a swallowed error that “shouldn’t happen” hides the fact that it did.
Fail fast vs fail soft
Two opposite responses to trouble, each right in its place:
| Fail fast | Fail soft (graceful degradation) | |
|---|---|---|
| Behavior | Stop immediately, surface the error | Continue with reduced functionality |
| Best for | Programmer bugs, broken invariants | Expected, recoverable conditions |
| Example | Corrupt internal state → crash loudly | One noisy frame → drop it, keep decoding |
The art is matching the response to the cause. A violated internal invariant means your program is wrong — fail fast, crash loudly, fix the bug. A noisy radio frame means the world is messy — fail soft, skip it, carry on. Confusing the two is a classic mistake: crashing on every bit of expected noise makes a system useless, while soldiering on with corrupt internal state makes it dangerous.
Graceful degradation is the broader principle behind fail-soft: when part of a system can’t function, the rest keeps working at reduced capability rather than collapsing entirely. A streaming decoder that hits an undecodable frame should drop it and keep processing the stream, not halt.
Idempotency and retries
Because failures trigger retries — a timeout, a dropped connection, a restarted process — operations that might run more than once should be idempotent: running them twice has the same effect as running them once. Setting a value to x is idempotent; appending x to a list is not. When an operation is idempotent, a retry after an ambiguous failure is safe; when it isn’t, retries risk duplicates and corruption. Designing for idempotency is what makes retry logic trustworthy in any system that can fail partway through.
Putting it together: a resilient radio decoder
These ideas converge sharply in a real-time radio decoder, the kind at the heart of GopherTrunk. Signals from the air are never clean: there’s background noise, fading, interference, dropped samples when the hardware can’t keep up, and frames that arrive truncated or corrupted. The decoder must absorb all of this without crashing.
A robust design applies everything from this lesson:
- Errors are normal — a malformed frame is expected input, handled on the main path, not an exceptional event.
- Validate at the boundary — check frame length, sync words, and checksums the moment bytes arrive; reject the bad ones cleanly.
- Fail soft — drop an undecodable frame and keep processing the stream; one bad frame must not kill the pipeline.
- Graceful degradation — under heavy noise, output fewer valid messages rather than collapsing.
- Fail fast on bugs — if an internal invariant breaks (a buffer index is impossible), that’s a programmer error worth surfacing loudly.
This robustness is exactly what makes streaming pipelines viable — see how the stages connect in concurrency and pipelines — and it’s only trustworthy if you prove it under bad inputs, which is the job of testing. A decoder that survives noise, drops, and malformed frames in tests is one you can trust on the air.
Quick check: a radio decoder receives a malformed frame from a noisy signal. What's the robust response?
Recap
- Errors are normal — design the error path as a first-class concern, not an afterthought.
- Know the styles — exceptions, explicit returns, and Result types; the modern lean is toward explicit, visible handling.
- Validate at boundaries — distrust external input at the edge so internal code can trust its invariants.
- Fail fast vs fail soft — crash loudly on programmer bugs, degrade gracefully on expected, recoverable trouble.
- Idempotency — make retry-able operations safe to run more than once.
- Resilience in practice — a radio decoder must tolerate noise, drops, and malformed frames without crashing.
Next up: Module 4 begins by asking what design patterns even are — what are patterns.
Frequently asked questions
Are errors really "normal" rather than exceptional?
Yes. Networks drop packets, files go missing, users type garbage, and radio signals arrive full of noise. These are everyday occurrences, not rare anomalies. Robust code treats error paths as a first-class part of the design, not an afterthought bolted on at the end.
What is the difference between failing fast and failing soft?
Failing fast means stopping immediately when something is wrong — surfacing the error loudly so it can’t propagate silently. Failing soft (graceful degradation) means continuing with reduced functionality. You fail fast on programmer errors and broken invariants, and fail soft on expected, recoverable conditions like a noisy input.
What does idempotent mean and why does it matter?
An idempotent operation produces the same result whether it runs once or many times. It matters because failures often trigger retries; if “process this frame” or “create this record” is idempotent, a retry after a timeout can’t cause duplicate work or corruption.