Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
proposal: Go 2: counter proposal to error values (v2) #31111
This is a proposal for adding error wrapping to go.
It is a counter-proposal to Go2 error values (the original proposal).
Please share feedback, opinions etc in this issue.
Find the proposal details in https://github.com/JavierZunzunegui/xerrors.
At a high level, compared to the original proposal, this one:
There was a first iteration
We agree that
I don't understand this. Errors with stack information will have the same problem as the current proposal. Errors without stack information will not, also the same.
The substantive differences seem to be:
Thanks for taking the time to improve and clarify your proposal. Speaking for myself, I don't see anything here that causes me to rethink our current proposal.
In this proposal wrapping is not an interface but a concrete type,
Also in the original while
In this proposal, errors only hold the information of that error. Stack information is an error, namely
Sure. It will be much easier to do here since only
No, I meant how would
No: except that they have different stack frames. And it isn't necessary that every error implement something, only that the recursive comparison function ignores frames.
I see. For reference, PathError is
At that point a
Of course this is a breaking change, but in the meantime what is broken is not
The point still remains. The or the comparison function ignores the frames is a red flag to me - want a reflect based method comparing two types that distinguishes based on the type of a field? That is 'reflection magic' and imho is a symptom of a flawed design. Is there anywhere else in the standard library where such approach is taken?
Also, you focus on frames but maybe, down the line, some other similar property wants to be added. Then you have to add more reflection magic. In this proposal there is nothing special about