In most situations panicking and deferencing a null pointer leads to the exact same scenario: The binary crashes. You can unwind and catch panics in Rust, but I’m not sure if that would have helped in this scenario as it might have immediately went directly into the fault code again.
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++.
> In most situations panicking and deferencing a null pointer leads to the exact same scenario: The binary crashes.
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.
In most situations panicking and deferencing a null pointer leads to the exact same scenario: The binary crashes. You can unwind and catch panics in Rust, but I’m not sure if that would have helped in this scenario as it might have immediately went directly into the fault code again.
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++.
> In most situations panicking and deferencing a null pointer leads to the exact same scenario: The binary crashes.
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.
Yes! We’re in absolute agreement here! That’s why I said «most situations» and not «all situations».