There has to be a better way.
It makes me think Go's comprehensive error handling can be compared to the performance of C. If you need it, it's great; if you don't need it, the effort you invest in it will detract from something you do need.
It's still a big issue overall.
From my experience with Go I find that only these lines fade into the background: something, err := someFunc() if err != nil { return nil, err }
I find that whenever any actual error handling logic beyond forwarding tends to really jump out at me in code reviews and such.
I think that the try() stuff removing the humdrum repetition is a good idea precisely because it makes all explicit error handling stand out like a beacon. I might name it "pass" or something but that's not as important. If I recall correctly, it vaguely resembles a solution you recommended to me on at least one occasion.
Keeping things as they are seems to me like the worst possible option.
I agree that "try" is better than the status quo, not because the if statements are lulling, but because they have the effect of triple-spacing Go code and making it harder to read.
My intuition is it will alleviate that but I’m not sure.
To be honest I'm not sure what you're suggesting at all. The reason the default error handling strategy for so man languages is to defer upwards is because that's by far the most convenient behavior for development, and is not the worst decision in prod.
Folks don't seem to find it confusing. Their programs crash with a stack trace. Certainly exception propagation has its own issues, but the default strategy isn't a thing I'd call out as bad. Indeed, if anyone can't produce a good crash-to-stack (cough, Haskell, cough) they get called "unfriendly" for developers.[1]
Meanwhile, I'm hardly the only voice in the choir of folks saying that Golang's error handling is frustratingly repetitive and can sometimes introduce surprising issue due to variable reuse, capture and shadowing.
> I agree that "try" is better than the status quo, not because the if statements are lulling, but because they have the effect of triple-spacing Go code and making it harder to read.
Both of these can be true without invalidating each other.
[1]: This is not to say we can't do better. Common Lisp is quite rightly famous for its Conditions and Restarts which are (imo, of course) pretty much the best error handling system ever created, allowing developers to embed recovery strategies AND rich exceptions in their code with syntactically and semantically obvious constructs and then pass the calling code the responsibility of choosing a mitigation strategy (or crashing).
By default, an ignored return code does nothing. The situation is shuffled under the rug.
By default, an ignored exception is loud.
Error codes have to be handled to become louder.
Exceptions have to be handled to become quieter.
The control flows underlying exceptions are syntactically invisible except at the source and destination sites. However, they reliably occur. They reliably occur because they are invisible. If exceptions had to be propagated by some visible assistance through all the layers they cross, they would become unreliable.
The problem/trade-off with exceptions (the bad aspect of how they are invisible in their own way) is that if we have statements like S1; S2; S3, we can never be sure that S2 is reached, or if S2 is reached then S3. S1 can call some function that throws, and so can S2 or S3.
Exceptions can cause partially executed statement flows to be unexpectedly abandoned. And that means that whatever those statements were doing remains half done because the programmer assumed that if S1 is reached, then S2 and S3 are an iron-clad given.
Programmers using exception-based languages have to train themselves to use unwind protection mechanisms in all situations fitting the pattern that "if we have executed S1, then S2 must execute to complete/undo/clean-up whatever S1 started". They must never rely on ordinary sequencing, except when it is obvious that the code doesn't throw (for whatever reason: triviality, or all being in the same module put together by that programmer or whatever). If any external code is involved (statements inserted by a macro, foreign callbacks, calls into third party stuff), all bets are off.
Obviously, Go does some things to mitigate the risk of ignored error returns; the damnable use requirement means that multi-valued functions returning errors either have to explicitly ignore the error by assigning it to "_", which feels as squicky as it should, or be assigned to a variable with which (usually) something must later be done.
It's not perfect, I'll freely concede.
Yeah, that is a problem. At least they had to manually type it out and (maybe) think about how to handle the error during that time. To streamline this is to further exacerbate the issue. They will do a try/catch try/defer `log.Println`.
With Python try/catch allows for ultimate laziness. It allows for 1,000 line try/catch blocks that can hide/capture errors that bubble up from anywhere. Of course this is bad development but it's possible. Currently with Go it is impossible to forget about error handling. You have to consciously make a choice on what to do with it. Even if that choice is to log/print it out.
Usually the answer is to wait for an actual exception and if it's not something you could actually anticipate, then write a tiny try block that just handles the exception. The whole point being that I want it to fail if there is an unknown exception. Which in Go, you wont fail at runtime if you are just printing errors as a habit( I think, I have not done much with go).
That said, a lot of times it makes sense to return errors, and perhaps there in lies the difference between an exception and an error.
You’re describing some other language that forces you to deal with errors, like Haskell or Rust.
A bare
io.WriteString(w, “ok”)
a, b := someFunc()
fmt.Println(b)
It's not a big deal.
A quick work around for that example would be to a line: `b = b`.
Go vet complains but it builds and runs.
There are actually better ways. Rust and Haskell not only fix this problem without breaking function composition... they make it so that the compiler is able to catch missing error handling logic.
The golang way of doing this is not the ideal way, but it does fix your issue with python.
Not true at all. The easiest example is:
func main() {
fmt.Println("")
}
I get that Go is targeting a systems niche where error handling is more sensitive. I think there will be fewer complaints about Go's error handling when people get a better sense for when to use it.
Just compare how good the error handling is in OCaml: http://keleshev.com/composable-error-handling-in-ocaml
They are strings. They are implementation of interface with a single `to_string` method, after you got `error`, you can't say (you could use switch on type, but you should guess which type could it be), so basically you have an opaque object with a single `to_string` method, which is equivalent to string.
I can't fancy a more error prone way than that which Go choose. How you match the errors, you match strings? You match types? You don't even know what types could there be, since all what the type system says is that function returns error.
do_something if err
value, err := os.Open(filename)
exit_on_error(err)
if err != nil {
fmt.Println("Something went wrong!")
os.Exit(1)
}
value, err := os.Open(filename)
handle_error(err, ERROR_FILE_OPEN)
if (error) return error;
if err { return err }
That said, I still support `try()`. It looks good to me, especially coming from Rust.
But "Go users like it" does imply "therefore it's not too badly mismatched to what go users are trying to do with it". Likewise, "Non-go users don't like it" implies "therefore it probably isn't a perfect fit for what non-go users are trying to do".
not the end of the world, just sad. i do wish there were a type-unified zero value, or that "" and 0 were the same as nil, or some other solution here