Comment by ethin
2 days ago
Not really. This is like if the char* were an Option<String> but you had programs which stupidly didn't check if the Option had something and assumed it always did. As others have said, Rust would not prevent this.
2 days ago
Not really. This is like if the char* were an Option<String> but you had programs which stupidly didn't check if the Option had something and assumed it always did. As others have said, Rust would not prevent this.
`Option<String>` or `Result<String>` forces the check at the callsite. Unlike C, you cannot forget that the function can error. This absolutely helps prevent issues like this.
Now, the decision to return `"*"` instead of letting poorly written code crash on `NULL` is not good either.
I don't think it's that people forget it while writing the code, it's that people want their program to work with as little effort as possible and decide to ignore it "for now". And that definitely can happen with Option and Result as well. There's no protection for not checking return values, and it's probably not even possible to protect against (in entirety)
Well they would use `unwrap` if they were lazy, but at least that would be quite visible in the code and would not result in undefined behavior due to operating on a null value. And there might be a group of developers who first choose to use .unwrap. I hope it is the minority.
Given how easy it is to just forward that error to the caller, I think most Rust developers would just choose to do that.
1 reply →
> There's no protection for not checking return values, and it's probably not even possible to protect against (in entirety)
That's exactly what you get with Result and Option, it's impossible to forget.
Compare:
To:
12 replies →