Of course, if that code had been written in Rust, the compiler would have caught the bug... no tests necessary, and no need to stick to clever coding patterns and write your own wrappers.
I know she likes her C, but I wonder if she'll eventually come around, drawn by the better reliability.
kevin_thibedeau•2h ago
This isn't C. At least denigrate the correct language.
The problem here is a flawed object design that requires external knowledge of when methods can be called. The fix is to detect invalid calls to value(), log/print to stderr, and call abort(). With a suitable test suite these logic errors will reveal themselves before a release build.
kelnos•2h ago
> The fix is to detect invalid calls to value(), log/print to stderr, and call abort().
That is what the code does:
> > Now, had that code ever run, it would have CHECKed and blown up right there, since calling .value() after it's returned false on the pass-fail check is not allowed.
Sure, it also makes sure that the check has been done before calling either .value() or .error(), but that isn't really relevant to the issue at hand: the program aborts if you call the wrong one of those two based on what the object holds.
> With a suitable test suite these logic errors will reveal themselves before a release build.
This is why I prefer Rust's approach with Result: the normal way of using it[0] means that I can't use it incorrectly. If I try to, it will be caught at compile time, and I don't need to write and maintain a test for something so stupidly trivial.
[0] Yes, I can use unwrap() and kill those guarantees. I make a habit of very rarely using unwrap(), and when I do, I write a comment above the line that details why I believe it's safe and will never panic.
phyzome•1h ago
Eh, I can't tell C from C++, as I've never really programmed in either. But you knew what I meant anyhow.
phyzome•3d ago
I know she likes her C, but I wonder if she'll eventually come around, drawn by the better reliability.
kevin_thibedeau•2h ago
The problem here is a flawed object design that requires external knowledge of when methods can be called. The fix is to detect invalid calls to value(), log/print to stderr, and call abort(). With a suitable test suite these logic errors will reveal themselves before a release build.
kelnos•2h ago
That is what the code does:
> > Now, had that code ever run, it would have CHECKed and blown up right there, since calling .value() after it's returned false on the pass-fail check is not allowed.
Sure, it also makes sure that the check has been done before calling either .value() or .error(), but that isn't really relevant to the issue at hand: the program aborts if you call the wrong one of those two based on what the object holds.
> With a suitable test suite these logic errors will reveal themselves before a release build.
This is why I prefer Rust's approach with Result: the normal way of using it[0] means that I can't use it incorrectly. If I try to, it will be caught at compile time, and I don't need to write and maintain a test for something so stupidly trivial.
[0] Yes, I can use unwrap() and kill those guarantees. I make a habit of very rarely using unwrap(), and when I do, I write a comment above the line that details why I believe it's safe and will never panic.
phyzome•1h ago