Pretty sure it's C++.
inb4 someone yells Rust. No, your `.unwrap()` happily panics in Rust too.
inb4 someone yells Rust. No, your `.unwrap()` happily panics in Rust too.
1. You have to explicitly add `unwrap()`, in C you just have to forget to add a null check which is a lot easier to do. The compiler won't remind you like it does in Rust. The bug is opt-out-if-you-remember not opt-in-if-you're-lazy.
2. The crash is safe. Usually a null pointer crash is safe but I've definitely seen cases where it leads to impossible-to-debug random failures.
3. You can see `unwrap()`s in code review easily.
4. You can actually catch panics, which is probably a good idea in high availability systems like a web server. I don't know if people actually do this in practice though.
Usually it's possible to write similar bugs in Rust but it's also far less likely that you would (though it does definitely happen). So Rust does at least help with this even if it doesn't fully prevent the issue.
Yeah, definitely. And the equivalent without optional types, dereferencing a null pointer, might happen because they don't even realize it could be null in the first place. Not everyone writes "assert(ptr != 0)" every time they assume a pointer isn't null, because it happens frequently (if the code doesn't use references enough, which IIRC happens with Google).
When you have an option type, you're made aware of it explicitly, and calling `.unwrap()` should, like you said, raise alarm bells and make you think anout whether you actually want to crash the program.
However, I would assume that the presence of an «unwrap» would have been caught in code review, whereas it’s much harder to be aware of which pointers can be null in Java/C++.
This is a false and dangerous misconception people seem to get wrong a lot of the time. There's no guarantee that's the case, especially when working in C where pointers are often subscripted.
It's the common behavior that a trap occurs but nothing dictates that's actually what will happen.