5 ms·
I agree that Rust's approach is better. I'm questioning the claim that Go "forces you" to handle errors, since to my understanding with Go someone can just esch
by Ukv 5mo ago
I agree that Rust's approach is better. I'm questioning the claim that Go "forces you" to handle errors, since to my understanding with Go someone can just eschew that 3-line boilerplate, silently ignoring the error, and still use the result (which is bad).
- 4ndrewl 5mo agoThe point being that's how you've decided to deal with the error, by ignoring it.
- Ukv 5mo agoSilently ignoring errors by leaving out some boilerplate doesn't really seem like an active/forced decision, or a selling point over the languages it disparages ("[...] hellscape doesn't make errors disappear, it just hides them"). Then that the correct path is the one of more resistance seems poor design, in my surface-level opinion.
- 4ndrewl 5mo agoIt is a decision though, and one you have to consciously make for each and every occurrence. You can't just hope some catch block will eventually handle it...
- Ukv 5mo agoI may be missing something, but I don't see how just forgetting to handle/propagate the error (and, say, causing data corruption by continuing with whatever empty/partial return value the function happens to give) would be a conscious decision. Even when it is intentional, like writing some quick/dirty code and planning on handling errors properly later, I'd imagine it's difficult to grep for instances of unchecked errors in the way you can with `.unwrap()` - though tooling should help.