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.
Patterns for Defensive Programming in Rust
51–60 of 99 posts
Re: Patterns for Defensive Programming in Rust
#52Indexing into arrays and vectors is really wise to avoid. 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.
Funny, it's really the same thing, why Rust people say we should abandon C. Meanwhile in C, it is also common to hand out handle instead of indices precisely due to this problem.
In rust, handing out indexes isn’t that common. It’s generally bad practice because your program will end up with extra, unnecessary bounds checks. Usually we program rust just the same as in C - get a reference (pointer) to an item inside the array and pass that around. The rust compiler ensures the array isn’t modified or freed while the pointer is held. (Which is helpful, but very inconvenient at times!)
Re: Patterns for Defensive Programming in Rust
#53Indexing into arrays and vectors is really wise to avoid. 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.
> Cloudflare had its unwrap fiasco,
Was it a fiasco? Really? The rust unwrap call is the equivalent to C code like this:
int result = foo(…);
assert(result >= 0);
You can write buggy code in rust just like you can in any other language.
Re: Patterns for Defensive Programming in Rust
#54Indexing into arrays and vectors is really wise to avoid. 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.
> Cloudflare had its unwrap fiasco, Was it a fiasco? Really? The rust unwrap call is the equivalent to C code like this: int result = foo(…); assert(result >= 0); If that assert tripped, would you blame the assert? Of course not. Or blame C? No. If that assert tripped, it’s doing its job by telling you there’s a problem in the call to foo(). You can write buggy code in rust just like you can in any other language.
The point is Rust provides more safety guarantees than C. But unwrap is an escape hatch, one that can blow up in your face. If they had taken the Haskell route and not provide unwrap at all, this wouldn't have happened.
Re: Patterns for Defensive Programming in Rust
#55Earlier quoted context omitted.
> Cloudflare had its unwrap fiasco, Was it a fiasco? Really? The rust unwrap call is the equivalent to C code like this: int result = foo(…); assert(result >= 0); If that assert tripped, would you blame the assert? Of course not. Or blame C? No. If that assert tripped, it’s doing its job by telling you there’s a problem in the call to foo(). You can write buggy code in rust just like you can in any other language.
The point is Rust provides more safety guarantees than C. But unwrap is an escape hatch, one that can blow up in your face. If they had taken the Haskell route and not provide unwrap at all, this wouldn't have happened.
https://hackage.haskell.org/package/base/docs/Data-Maybe.htm...
"The fromJust function extracts the element out of a Just and throws an error if its argument is Nothing."
Re: Patterns for Defensive Programming in Rust
#56Indexing into arrays and vectors is really wise to avoid. 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.
> Cloudflare had its unwrap fiasco, Was it a fiasco? Really? The rust unwrap call is the equivalent to C code like this: int result = foo(…); assert(result >= 0); If that assert tripped, would you blame the assert? Of course not. Or blame C? No. If that assert tripped, it’s doing its job by telling you there’s a problem in the call to foo(). You can write buggy code in rust just like you can in any other language.
This is the equivalent of force-unwrap in Swift, which is strongly discouraged. Swift format will reject this anti-pattern. The code running the internet probably should not force unwrap either.
Re: Patterns for Defensive Programming in Rust
#57In the first example, the match feels extremely overkill. Vec.first() exposes the correct semantic (as does Vec.iter().nth(0) for the more general case), returning an Option.
Re: Patterns for Defensive Programming in Rust
#58Earlier quoted context omitted.
> Cloudflare had its unwrap fiasco, Was it a fiasco? Really? The rust unwrap call is the equivalent to C code like this: int result = foo(…); assert(result >= 0); If that assert tripped, would you blame the assert? Of course not. Or blame C? No. If that assert tripped, it’s doing its job by telling you there’s a problem in the call to foo(). You can write buggy code in rust just like you can in any other language.
The point is Rust provides more safety guarantees than C. But unwrap is an escape hatch, one that can blow up in your face. If they had taken the Haskell route and not provide unwrap at all, this wouldn't have happened.
Haskell’s fromJust, and similar partial functions like head, are as dangerous as Rust’s unwrap. The difference is only in the failure mode. Rust panics, whereas Haskell throws a runtime exception.
You might think that the Haskell behavior is “safer” in some sense, but there’s a huge gotcha: exceptions in pure code are the mortal enemy of lazy evaluation. Lazy evaluation means that an exception can occur after the catch block that surrounded the code in question has exited, so the exception isn’t guaranteed to get caught.
Exceptions can be ok in a monad like IO, which is what they’re intended for - the monad enforces an evaluation order. But if you use a partial function like fromJust in pure code, you have to be very careful about forcing evaluation if you want to be able to catch the exception it might generate. That’s antithetical to the goal of using exceptions - now you have to write to code carefully to make sure exceptions are catchable.
The bottom line is that for reliable code, you need to avoid fromJust and friends in Haskell as much you do in Rust.
The solution in both languages is to use a linter to warn about the use of partial functions: HLint for Haskell, Clippy for Rust. If Cloudflare had done that - and paid attention to the warning! - they would have caught that unwrap error of theirs at linting time. This is basically a learning curve issue.
Re: Patterns for Defensive Programming in Rust
#59In the first example, the match feels extremely overkill. Vec.first() exposes the correct semantic (as does Vec.iter().nth(0) for the more general case), returning an Option.
That's fine but the matching exposes that you should also handle the "has more than one element" case. And in general it's pointing to the idea of "try to not separate checks from code that depends on those checks"
Re: Patterns for Defensive Programming in Rust
#60Indexing into arrays and vectors is really wise to avoid. 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.
> Cloudflare had its unwrap fiasco, Was it a fiasco? Really? The rust unwrap call is the equivalent to C code like this: int result = foo(…); assert(result >= 0); If that assert tripped, would you blame the assert? Of course not. Or blame C? No. If that assert tripped, it’s doing its job by telling you there’s a problem in the call to foo(). You can write buggy code in rust just like you can in any other language.
I think it's because unwrap() seems to unassuming at a glance. If it were or_panic() instead I think people would intuit it more as extremely dangerous. I understand that we're not dealing with newbies here, but everyone is still human and everything we do to reduce mistakes is a good thing.