3 ms·
> The output of panic will only ever be seen by the programmer. Obviously not if it's used for input errors (network failure). Crashing assertions are made for
by p0nce 10y ago
> The output of panic will only ever be seen by the programmer.
Obviously not if it's used for input errors (network failure).
Crashing assertions are made for bugs, not input errors.
- kibwen 10y agoPlease read the rest of my comment. It's not used for input errors.
- p0nce 10y agoThis is invalid since nothing in the compiler forces you to remove the .unwrap() so it's safe to assume it will not be done before production. The whole "but this is just for prototyping" is a logical fallacy, as you know we have tons of prototypes in production ;)
- kibwen 10y agoI admit that I'm having a hard time seeing this criticism as anything but overblown. Finding usage of unwrap is trivially easy via textual search. Furthermore, Clippy can be used to automatically forbid usage of unwrap for your entire team ( https://github.com/Manishearth/rust-clippy/wiki#option_unwrap_used https://github.com/Manishearth/rust-clippy/wiki#option_unwra... ). Furthermore, even when you hit a panic, it tells you which line of code in which file triggered it so that you can fix it immediately. Furthermore, the Rust community has a strong and long-entrenched proscription against libraries which unwrap rather than handle errors. We can agree in the cynical interpretation of the laziness of programmers, but the mitigations in this case are so trivial, and the stakes so low, that focusing on unwrap as a point of contention is a poor use of energy.