3 ms·
> Moreover, panic!()’s are hiding even in the most innocious places like unwrap() and expect() calls unwrap and expect aren't "innocuous places where panic is
by pdpi 2y ago
> Moreover, panic!()’s are hiding even in the most innocious places like unwrap() and expect() calls
unwrap and expect aren't "innocuous places where panic is hiding". The whole point of unwrap and expects is that you're effectively saying "Hitting a None/Err here is impossible, so seeing them should be treated as a correctness error".
- zamalek 2y agoFurthermore > a panic!() or an abort() are much more annoying to catch and handle. By design. If you're hoping to catch a panic, then you're doing it woefully wrong. Catching panics is correct only in extremely niche scenarios. Panic-free Rust code can sometimes be challenging, if a dependency incorrectly asserts an unwrap/expect, but the Rust community tends to hold itself to a higher standard than that. Other things, > Most of it is the low-level nitty-gritty, which Rust is not particularly good at. I don't feel like this was motivated anywhere, just asserted at the end. My opinion is that Rust gives you more tools to make invalid states unrepresentable - this can drastically lower cognitive burden when working on the code. > Bounds checks are rarely performed in the compiletime and we have to pay their price at the runtime. This is a significant performance hit for coders. Rust is extremely good at eliding bounds checks. If you attempt to write C++ in Rust (e.g. a moving pointer/slice) then you're probably going to trip these heuristics up, idiomatic Rust (heavy iterator usage) generally results in fewer bounds checks. > The ownership model is not particularly useful to coders. Maybe not useful, but certainly unlikely to be a hindrance. The ownership model generally maps extremely well to the CS101 concept of Input -> Processing -> Output, which coders are (and UIs aren't, if you've ever wondered why its still mostly an unsolved problem in Rust). You can do raw assembly in Rust too.
- SAI_Peregrinus 2y ago> Catching panics is correct only in extremely niche scenarios. Catching panics is correct when the panic would cause unwinding across a FFI boundary. I can't think of anywhere else where I wouldn't be very suspicious seeing a catch_unwind().
- int_19h 2y agoA good example of valid use of catch_unwind() would be for a desktop app to try to save a copy of any unsaved in-memory state before it crashes for good. Since invariants are already broken, it might or might not work, and may possibly save some garbage data, but it is much better than saving nothing at all. The one common thing for all such patterns is that they happen at or near the topmost layer of the app (e.g. around the main loop for GUI apps, or around the request handler for web apps).
- meltyness 2y agoYeah you can lint for "array-access." Logic written using iterators (streams for Java folk, comprehensions for python) doesn't fail in this way. Also still gens to very fast assembly like "looping and accessing" but with the added benefit of unambiguous terminating conditions, unless you go with fallible forms, which you can use to introduce ambiguous terminating conditions. Or if some other random access pattern is needed, implement the appropriate trait.
- Aurornis 2y agounwrap() and expect() are defined as panic-if functions. It’s one of the first things you learn when writing Rust code. Calling them innocuous or being surprised that they can panic suggests this person hasn’t really learned much Rust at all.