Comment by Ferret7446 a day ago
This is why a lot of Go users like its error handling as it is. It forces you to explicitly think about how you want to handle the error.
Of course, it can't prevent people from pasting an error handler everywhere instead of thinking about it, which I think are the same people who hate Go's error handling
I think they are actually pretty different in approach. rust sprinkle ”?” everywhere and wants to avoid dealing with the error, and golang is more explicit and robust handling. sure, most is similar if it is just ”if err return err” but I have definitely seen more ”extreme” and correct error handling in golang, whereas in rust the convenience of just bubbling it up wins. I still prefer rust, but I am not sure the comparison is as close as people claim
> rust sprinkle ”?” everywhere and wants to avoid dealing with the error
You certainly must handle the error if you want your computation to continue.
> golang is more explicit
Not sure how golang is more explicit. In functor-based style, an error-prone computation stops if it yields an error and that error isn't handled explicitly. That makes sure that any successful computation is based on expected behaviour from beginning to end.
> and robust
Likewise, that's a claim based on nothing. Forcing developers to write a little snippet of code everywhere lest their code has a bug does not make code more robust.
> but I have definitely seen more ”extreme” and correct error handling in golang, whereas in rust the convenience of just bubbling it up wins.
You also have the option to match a result for lower-level error handling in rust.
Claiming that "convenience" makes rustaceans not use that option is like claiming that gophers don't check the error content because it's faster to panic.
My bad, I should have written in my experience working on larger codebases. It was a bit too general. It was never about the semantics about the language, but about allowing developers to make the correct choice. Kind of why Golang was built for Google I guess. In practice I've found Golang developers to handle errors where appropriate, where in (binary) Rust applications I've usually found `anyhow` everywhere with `?` to be a bit of a silent issue.
You're right that the languages have the same capability. The terseness can IMO both be a strength and a liability.
Sprinkling "?" everywhere and the properties you mentioned are not really a different approach by the language but by the (some) users.
I am not even sure if Rust is that more convenient in this regard generally. To actually be able to use a ?, you have to actually define a conversion for the error types (which again you define yourself) or explicitly opt into a solution like anyhow, which would allow to use them almost blindly.
In Go, you can just blindly put your boilerplate (potentially using IDE shortcuts/autocomplete as some suggested to me or told me about).
> whereas in rust the convenience of just bubbling it up wins
Not necessarily, I have seen so many ways of error handling at this point, and what is best probably may depend on the individual situation.
In my personal experience, neither using anyhow nor my current default approach (custom error struct and `map_err(Error::EnumVariant)?` have prevented me from acknowledging that a potential error and thinking about if I should handle it in the current function or bubble up, although I agree that the perceived cost of handling an error may be increased, because you add comparatively more code in Rust.
Further, I feel like what Rust does is already the upper limit of boiler plate I can tolerate, although I am not sure there is a better way of this type of error handling.
The difference between just "?" and "?" + <good error message> is much greater than the difference between "if err != nil { return err }" and "if err != nil { return fmt.Errorf("<good error message") }".
Part of it is the syntactical easiness of "?", how can any other solution compete with the ease of typing a single character?
But mostly, it's that "fmt.Errorf" is built-in and widely used, as opposed to whatever library you need to go out of your way to choose to be able to easily annotate errors in Rust.
Technically it doesn't because you can just ignore the error return and keep going anyway, its only a lint failure not to do something with a returned error. The language has a culture of dealing with the error straight away but the language doesn't enforce it.
In Java with checked exception you have no choice, you either try/catch it or you throw(s) it and are forced to handle it or its a compile error. Java does this aspect better, error handling features are relatively weak in Go but people have utilised the multiple returns well to make the best of it.
> In Java with checked exception you have no choice, you either try/catch it or you throw(s) it and are forced to handle it or its a compile error. Java does this aspect better
You don't have to give any consideration to that if you don't want to; you can always just catch the exception and rethrow it as a RuntimeException.
I "hate" GOs error handling because of repetitive and verbose boiler plate when it comes to error handling.
Rust has almost the same error handling concept, but with way less boilerplate.
And Rust actually syntactically forces to handle the error case, because you can't just access the return value when there are potential errors