Repository navigation
proposal: Go 2 error values #29934
Description
This issue is for discussion of our Go 2 error values proposal, which is based on our draft designs for error information and formatting.
This proposal will follow the process outlined in the "Go 2, here we come" blog post: we will have everything ready to go and checked in at the start of the Go 1.13 cycle (Feb 1), we will spend the next three months using those features and soliciting feedback based on actual usage, and then at the start of the release freeze (May 1), we will make the "launch decision" about whether to include the work in Go 1.13 or not.
Update 2019-05-06: See launch decision here: #29934 (comment)
Activity
mvdan commentedon Jan 25, 2019
Assuming this is accepted and implemented before generics, would the design be adapted in a potential redesign of
stdwith generics?mpvl commentedon Jan 25, 2019
@mvdan We think the design not using generics resulted in a slightly nicer API in the end. So we will probably not do so. That said, it can't be ruled out there will be additional API using generics.
networkimprov commentedon Jan 25, 2019
Could a change in output break consumers which compare it with a hard-coded string, e.g. test code?
neild commentedon Jan 26, 2019
Conceivable, but since the
fmtpackage currently treats%+videntically to%vfor any type which implements theerrorinterface there isn't a strong reason for users to use the former to format errors at the moment.Sherlock-Holo commentedon Jan 27, 2019
I wonder why
xerrors.Errorf("new error: %w", baseErr)%wmust at the end, I think when print the error, it should benot
networkimprov commentedon Jan 27, 2019
Agreed it's odd that the format string is an output-type controller, rather than a flag in the verb like
%$v.Also, have the authors considered providing this, which is conspicuously absent in package fmt:
This works like
errors.New(fmt.Sprint(a, b))Just as Errorf works like
errors.New(fmt.Sprintf(s, a, b))neild commentedon Jan 27, 2019
What are the arguments for a flag over a verb? I don't see a strong argument for one over the other and
%whas some mnemonic value, but perhaps I'm missing something.I think this is orthogonal to the rest of the proposal, but it doesn't seem unreasonable. On the other hand, I don't think I've ever felt the absence of this function.
networkimprov commentedon Jan 28, 2019
I'm referring to this output-type control via the format string: "if ... the format string ends with
: %s,: %v, or: %w, then the returned error will implement FormatError." Why not a flag for %s & %v?The easiest way to print an error is:
fmt.Println("this happened: ", err)The easiest way to make an error should be:
fmt.Error("this happened: ", err)jba commentedon Jan 28, 2019
The only existing flags that don't have a meaning for %s and %v are space and 0. But those both feel wrong, so we'd need to make up a new flag. That means one could potentially use that flag with any verb, but it would be meaningless except for %s and %v. That feels wasteful—flags and verbs should combine orthogonally to (almost) always produce a useful result (with space and 0 themselves being the notable exceptions).
ericlagergren commentedon Jan 28, 2019
To be clear: does this mean each call to fmt.Errorf will collect a stack trace?
neild commentedon Jan 28, 2019
A single stack frame, not a full trace.
tandr commentedon Jan 28, 2019
Would it be possible to make it "adjustable" somehow? In our home-made logging wrapper we have noticed that we have to pull a couple or 3 frames to get to "the caller of interest", so printout looks more or less pointing to the place where
logwrap.Print(err)function was called.If this is becoming a part of the standard, in case when wrapper (or utility method) is created to simplify an error creation, I would like to report the place where that method was called from, and not the utility method itself.
We did it by (arguable not so elegant) way as adding a parameter "how big is the stack offset" to the logging function, but I am not sure if that's the only option here. Adding special format symbol for stack, with number of frames interesting might be one of possible approaches.
445 remaining items
fatih commentedon Feb 26, 2020
Thank you @changkun for the links.
@jba @rsc based on the links that @changkun provided, can we assume that error handling work is suspended (or paused)? If that is the case we should update the issue with a notice reflecting the latest status. There are many people (including me) assuming this is still and on-going work.
I was assuming that we would receive some of the functionality, such as stack frames and was planning accordingly for that internally at GitHub. I need to revisit my planning and inform teams at GitHub that the work on errors is delayed (or suspended) if that is the case.
fatih commentedon Feb 26, 2020
@JavierZunzunegui thanks for the link. Is there any additional benefit compared to
xerrors, which already includes frame info ?JavierZunzunegui commentedon Feb 26, 2020
(+) It provides much more formatting flexibility. Skip want you want, encode the others any way you want, if you want to you can even reverse the encoding order.
(+) Mixing non-zerrors with zerrors fares better than mixing non-xerrors with xerrors. Formatting only messes up locally (versus messing up the entire rest of the error in xerrors), and you always have the option to skip ayways (not so in xerrors).
(+) Easier to use. Your errors don't have to implement anything besides
Error() string, the library provides everything else.(?) performance haven't done the benchmark comparison yet, but will do.
(?) minimal API. Comes with being new, it makes it easier to understand but the desired 'utilities' are yet to come, with usage feedback.
(-) new and untested in production. You won't find libraries using it (yet?).
(-) v0.1.0. I'll try not to break things but that's not set in stone...
flibustenet commentedon Feb 26, 2020
About including frame, there are a lot of lib implementing this, and it's very easy to do, i did it myself to. But all of them are unusable in library if there is not at least a common interface to know if an error already embed the frame and how to print it.
JavierZunzunegui commentedon Feb 26, 2020
@flibustenet of course, the ideal place for any such solution is the standard library, but that is not happenning any time soon. We are in the same place with frames / formatting that we were with wrapping pre-1.13: multiple, sometimes poorly compatible frameworks. But that is the way to experiment and ultimately show, through experience, what is best, and guide the decision of what makes it to the standard library. That was very much the story of wrapping too.
knz commentedon Feb 26, 2020
The issue with zerrors linked above is that the error objects are not suitable for transporting over the wire in a distributed application. It's not possible to reliably inspect stack traces and frame information across servers.
See crdb's own errors replacement which supports network transport and is battle-tested in production.
knz commentedon Feb 26, 2020
the crdb errors package also has its own formatting protocol for
%+vwhich aims to fix many shortcomings of xerrors.ianlancetaylor commentedon Feb 27, 2020
@changkun We are unlikely to do anything about error handling any time soon. But this proposal is not about error handling. It is about error values. They are different things. See, e.g., the separate discussions of error values and error handling at https://go.googlesource.com/proposal/+/master/design/go2draft.md.
changkun commentedon Feb 27, 2020
gophun commentedon Jun 6, 2022
Shouldn't this issue be closed? The proposal was accepted and shipped with Go 1.13. As @ianlancetaylor pointed out this issue was about the error values proposal, not about error handling in general. This is currently the most commented open issue, so I was expecting something interesting going on here, but it's already done.
http2: remove use of DeepEqual for testing errors