It might not make sense to change it, because the wrong problem is trying to be solved.
The code that we are familiar with is not error handling.
if err != nil { return err }
This is error nil handling. At no point in this pattern is the value of an error handled.
If I were to demonstrate this in a different language, Ruby.
begin some_method_that_raises_an_error rescue => e # catch any exception retry e # throw it up again end
This relays the same behavior as the golang code. When we detect that an exception occurred and then reraise it. We just throw it up the stack.
In golang, we return it.
Where is the actual error handling occurring?
We’ve all had similar experiences of the failure of this pattern. For example, receiving a file not found error and then spending a large length of time tracing the original thrower of this error.
This is why I believe the try proposal (and others) are faulting. We don’t have a good pattern for actually handling errors.
I’ve see err.Error() string checking, type assertions, etc. to actually inspect the error.
We need a pattern for this inconsistency. It feels like xerrs might be solving this, but it also doesn’t feel complete yet.
