Patterns for Defensive Programming in Rust
by PaulHoule on 12/5/2025, 4:34:25 PM
https://corrode.dev/blog/defensive-programming/
Comments
by: stouset
Good article, but one (very minor) nit I have is with the PizzaOrder example.<p><pre><code> struct PizzaOrder { size: PizzaSize, toppings: Vec<Topping>, crust_type: CrustType, ordered_at: SystemTime, } </code></pre> The problem they want to address is partial equality when you want to compare orders but ignoring the ordered_at timestamp. To me, the problem is throwing too many unrelated concerns into one struct. Ideally instead of using destructuring to compare only the specific fields you care about, you'd decompose this into two structs:<p><pre><code> #[derive(PartialEq, Eq)] struct PizzaDetails { size: PizzaSize, toppings: Vec<Topping>, crust_type: CrustType, … // additional fields } #[derive(Eq)] struct PizzaOrder { details: PizzaDetails, ordered_at: SystemTime, } impl PartialEq for PizzaOrder { fn eq(&self, rhs: &Self) -> bool { self.details == rhs.details } } </code></pre> I get that this is a toy example meant to illustrate the point; there are certainly more complex cases where there's no clean boundary to split your struct across. But this should be the first tool you reach for.
12/5/2025, 7:27:47 PM
by: germandiago
Some of the advice is applicable tp C++ as well. Enums and such things with non-exhaustive checks all have warnings and setting warnings as errors helps.
12/6/2025, 5:45:11 AM
by: emschwartz
Indexing into arrays and vectors is really wise to avoid.<p>The same day Cloudflare had its unwrap fiasco, I found a bug in my code because of a slice that in certain cases went past the end of a vector. Switched it to use iterators and will definitely be more careful with slices and array indexes in the future.
12/5/2025, 7:58:13 PM
by: pornel
What's really nice is where you <i>don't</i> need defensive programming in Rust.<p>If your function gets ownership of, or an exclusive reference to an object, then you know for sure that this reference, for as long as it exists, is the only one <i>in the entire program</i> that can access this object (across all threads, 3rd party libraries, recursion, async, whatever).<p>References can't be null. Smart pointers can't be null. Not merely "can't" meaning not allowed and may throw or have a dummy value, but just can't. Wherever such type exists, it's already checked (often by construction) that it's valid and can't be null.<p>If your object's getter lends an immutable reference to its field, then you know the field won't be mutated by the caller (unless you've intentionally allowed mutable "holes" in specific places by explicitly wrapping them in a type that grants such access in a controlled way).<p>If your object's getter lends a reference, then you know the caller won't keep the reference for longer than the object's lifetime. If the type is not copyable/cloneable, then you know it won't even get copied.<p>If you make a method that takes ownership of `self`, then you know for sure that the caller won't be able to call any more methods on this object (e.g. `connection.close(); connection.send()` won't compile, `future.then(next)` only needs to support one listener, not an arbitrary number).<p>If you have a type marked as non-thread safe, then its instances won't be allowed in any thread-spawning functions, and won't be possible to send through channels that cross threads, etc. This is verified globally, across all code including 3rd party libraries and dynamic callbacks, at compile time.
12/6/2025, 2:02:15 AM
by: perching_aix
This made me wonder, why aren't there usually teams whose job is to keep an eye on the coding patterns used in the various codebases? Similarly like how you have an SOC team who keeps monitoring traffic patterns, or an Operations Support team who keeps monitoring health probes, KPIs, and logs, or a QA who keeps writing tests against new code, maybe there would be value to keeping track of what coding patterns develop into over the course of the lifetime of codebases?<p>Like whenever I read posts like this, they're always fairly anecdotal. Sometimes there will even be posts about how large refactor x unlocked new capability y. But the rationale always reads somewhat retconned (or again, anecdotal*). It seems to me that maybe such continuous meta-analysis of one's own codebases would have great potential utility?<p>I'd imagine automated code smell checking tools can only cover so much at least.<p>* I hammer on about anecdotes, but I do recognize that sentiment matters. For example, if you're planning work, if something just <i>sounds</i> like a lot of work, that's already going to be impactful, even if that judgement is incorrect (since that misjudgment may never come to light).
12/5/2025, 7:35:35 PM
by: adastra22
This is a great article. Anyone know more content like this?
12/6/2025, 4:33:29 AM
by: J_Shelby_J
Wow that’s amazing. The partial equality implementation is really surprising.<p>One question about avoiding boolean parameters, I’ve just been using structs wrapping bools. But you can’t treat them like bools… you have to index into them like wrapper.0.<p>Is there a way to treat the enum style replacement for bools like normal bools, or is just done with matches! Or match statements?<p>It’s probably not too important but if we could treat them like normal bools it’d feel nicer.
12/5/2025, 6:52:21 PM
by: brohee
The very useful TryFrom trait landed only in 1.34, so hopefully the code using unwrap_or_else() in From impl predates that...<p>Actually the From trait documentation is now extremely clear about when to implement it (<a href="https://doc.rust-lang.org/std/convert/trait.From.html#when-to-implement-from" rel="nofollow">https://doc.rust-lang.org/std/convert/trait.From.html#when-t...</a>)
12/5/2025, 6:16:28 PM
by:
12/5/2025, 11:31:53 PM
by: thatoneengineer
Aside from just being immensely satisfying, these patterns of defensive programming may be a big part of how we get to quality GAI-written code at scale. Clippy (and the Rust compiler proper) can provide so much of the concrete iterative feedback an agent needs to stay on track and not gloss over mistakes.
12/5/2025, 10:37:52 PM
by: lilyball
In Pattern: Defensively Handle Constructors, it recommends using a nested inner module with a private Seal type. But the Seal type is unnecessary. The nested inner module is all you need, a private field `_private: ()` is only settable from within that inner module, so you don't need the extra private type.
12/5/2025, 9:43:11 PM
by: Dowwie
I'm not reading a solid argument as to not use "..Defaults()" because doing so suggests that you may introduce a bug and therefore should be explicit about EVERYTHING instead? Ugh. Hard disagree.
12/5/2025, 8:05:43 PM
by: ggirelli
Loved the article, such a nice read. I am still slowly ramping up my proficiency in Rust and this gave me a lot of things to think through. I particularly enjoyed the temporary mutability pattern, very cool and didn't think about it before!
12/5/2025, 7:01:00 PM
by: quotemstr
The tech industry is full of brash but lightly-seasoned people resurrecting discredited ideas for contrarianism cred and making the rest of us put down monsters we thought we'd slain a long time ago.<p>"Defensive programming" has multiple meanings. To the extent it means "avoid using _ as a catch-all pattern so that the compiler nags you if someone adds an enum arm you need to care about", "defensive" programming is good.<p>That said, I wouldn't use the word "defensive" to describe it. The term lacks precision. The above good practice ends up getting mixed up with the bad "defensive" practices of converting contract violations to runtime errors or just ignoring them entirely --- the infamous pattern in Java codebases of scrawling the following like of graffiti all over the clean lines of your codebase:<p><pre><code> if (someArgument == null) { throw new NullPointerException("someArgument cannot be null"); } </code></pre> That's just noise. If someArgument can't be null, let the program crash.<p>Needed file not found? Just return ""; instead.<p>Negative number where input must be contractually not negative? Clamp to zero.<p>Program crashing because a method doesn't exist? if not: hasattr(self, "blah") return None<p>People use the term "defensive" to refer to code like the above. They programs that "defend" against crashes by misbehaving. These programs end up being flakier and harder to debug than programs that are "defensive" in that they continually validate their assumptions and <i>crash</i> if they detect a situation that should be impossible.<p>The term "defensive programming" has been buzzing around social media the past few weeks and it's essential that we be precise that<p>1) constraint verification (preferably at compile time) is good; and<p>2) avoidance of crashes at runtime at all costs after an error has occurred is harmful.
12/5/2025, 8:18:59 PM
by: Sunscratch
Nice article. The problem of multiple booleans is just one instance of a more general problem: when a function takes multiple arguments of the same type (i32, String, etc.). The newtype pattern allows you to create distinct types in such cases and enforce correctness at compile time.
12/5/2025, 8:56:07 PM
by: empath75
This is one of the best Rust articles I've ever read. It's obviously from experience and covers a lot of _business logic_ foot guns that Rust doesn't typically protect you against without a little bit of careful coding that allows the compiler to help you.<p>So many rust articles are focused on people doing dark sorcery with "unsafe", and this is just normal every day api design, which is far more practical for most people.
12/5/2025, 6:08:53 PM
by: schneems
This was posted with a (mostly) healthy discussion on lobste.rs, here's the link <a href="https://lobste.rs/s/ouy4dq/patterns_for_defensive_programming_rust" rel="nofollow">https://lobste.rs/s/ouy4dq/patterns_for_defensive_programmin...</a>
12/5/2025, 7:52:17 PM
by: tayo42
>Using _ as a placeholder for unused variables can lead to confusion<p>I would have guessed linters would have complained about what's being suggested there. Is the something special about var: _ thing that avoids it?
12/6/2025, 3:33:22 AM
by: torginus
Defensive programming is a widely known antipattern : <a href="https://wiki.c2.com/?DefensiveProgramming" rel="nofollow">https://wiki.c2.com/?DefensiveProgramming</a><p>The 'defensive' nature refers to the mindset of the programmer (like when guilty people are defensive when being asked a simple question), that he isn't sure of anything in the code at any point, so he needs to constantly check every invariant.<p>Enterprise code is full of it, and it can quickly lead to the program becoming like 50% error handling by volume, many of the errors being impossible to trigger because the app logic is validating a condition already checked in the validation layer.<p>Its presence usually betrays a lack of understanding of the code structure, or even worse, a faulty or often bypassed validation layer, which makes error checking in multiple places actually necessary.<p>One example is validating every parameter in every call layer, as if the act of passing things around has the ability to degrade information.
12/6/2025, 4:06:22 AM