News for hackers. Stuff that matters.
Re:Implications of Rewriting a Browser Component in Rust by dullgiulio on Thursday February 28, 2019 @12:41PM (#19273221)
But the parent's point remains: a Java NPE and a panic because of unwrap are really equivalent. Not really unsafe in the C sense, but equally bad as unhandled crashes.
Re:Implications of Rewriting a Browser Component in Rust by staticassertion on Thursday February 28, 2019 @06:07PM (#19276277)
There's one really major distinction - you can `grep` for `unwrap`. You could grep for null, but that won't tell you if an NPE elsewhere is possible, and it won't hit every single case (like 3rd party libs returning null).

Making bugs grep'able is huge.

Re:Implications of Rewriting a Browser Component in Rust by jononor on Thursday February 28, 2019 @06:12PM (#19276324)
Greppable also means it is trivially lintable. And the standard linter Clippy defaults since two years to disallow unwrap()
Re:Implications of Rewriting a Browser Component in Rust by Yoric on Thursday February 28, 2019 @03:43PM (#19274987)
Assuming that nobody catches the NPE by accident or error (according to my experience in Java, it's a pretty big assumption), yes, they pretty much are.

The big difference is that, in Java, you typically get your NPE because you didn't know/didn't check that your pointer could be `null` – in other words, the default behavior of the language is to NPE. In Rust, the default behavior of the language is to inform the developer that they need to check. They may decide to explicitly assert that the pointer is not null, causing a crash if it is, but that's a conscious choice.

For instance, in my Rust code, pretty much every occurrence of `unwrap()` or `expect()` contains a comment explaining which invariant guarantees that the call will succeed. I don't think I have ever seen any comments associated to a member access in Java.