This is the real danger of the pattern, isn't it? It fades into the background, lulling your eyes into skipping over what's potentially a major source of bugs.
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.
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.
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).
My intuition is it will alleviate that but I’m not sure.
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.