It doesn't exactly, no. There are linters and a compiler-enforced check preventing unused variables. Overall it's pretty easy to accidentally drop errors or overwrite them before checking.
It does. If a function returns a Result or Option type, you can't just use its data; you have to either automatically propagate the error case upward, pattern match on both the success and error cases, or just use ".unwrap()" and explicitly choose to crash in the case of an error. There's no implicit crash like there is in a language that lets you dereference null pointers.
It doesn't exactly, no. There are linters and a compiler-enforced check preventing unused variables. Overall it's pretty easy to accidentally drop errors or overwrite them before checking.
So no, it doesn't.
Well at least you shouldn’t be able to actually dereference a nil, right?
You'll get a runtime panic.
Hey, it's better than lurking undefined behavior and data corruption issues!
Doesn't keep your binary from crashing, though.
Sadly, and imo almost unforgivably in such a modern language, no
1 reply →
No language forces to handle errors. Even Rust.
> No language forces to handle errors. Even Rust.
It does. If a function returns a Result or Option type, you can't just use its data; you have to either automatically propagate the error case upward, pattern match on both the success and error cases, or just use ".unwrap()" and explicitly choose to crash in the case of an error. There's no implicit crash like there is in a language that lets you dereference null pointers.
let _ = works fine in Rust.
1 reply →