Proposal: add a package-level StackTrace() method

[Jonathan Hall]

I think it would be convenient to have a package-level StackTrace(err error) StackTrace method, as a bit of an analog to the Cause(err error) error method, which returns the earliest stack trace found in the composite error value.

This is something I have implemented in at least three packages myself now, but it seems likely to be of value to others, so I'm beginning to think perhaps it belongs here.

The reason it's not sufficient to simply call err.StackTrace(), is that an error may have been Wrap()ed multiple times, in which case one generally (if not always) wants the earliest stack trace. And:

cause := err.(causer)
stackTrace := cause.(stackTracer)

doesn't work, because generally the cause does not include a stack trace.

So my proposal is to add a package-level StackTrace() method such that one can do, for instance:

if stackTrace := errors.StackTrace(err); stackTrace != nil {
    fmt.Printf("Stacktrace: %+v\n", stackTrace)
}

If this proposal meets general approval, I can quickly submit a PR for further consideration.

[Dave Cheney]

I see the utility of this function, but like other similar requests for wrapping errors if they haven't already been wrapped etc, or only wrapping if haven't been annotated in a particular I'm wary because the logic is subtle and the result of errors.StackTrace(err) would work for you, but I'm sure someone else would want a single different version. At the moment I'm punting on this by giving you to tools to write this method yourself according to your specifications. I know it's not the answer you were looking for, but it's thr state of things today.

…

On Thu, 1 Dec 2016, 03:42 Jonathan Hall ***@***.***> wrote: I think it would be convenient to have a package-level StackTrace(error) method, as a bit of an analog to the Cause(error) method, which returns the earliest stack trace found in the composite error value. This is something I have implemented in at least three packages myself now, but it seems likely to be of value to others, so I'm beginning to think perhaps it belongs here. The reason it's not sufficient to simply call err.StackTrace(), is that an error may have been Wrap()ed multiple times, in which case one generally (if not always) wants the *earliest* stack trace. And: cause := err.(causer) stackTrace := cause.(.stackTracer) doesn't work, because generally the cause does not include a stack trace. If this proposal meets general approval, I can quickly submit a PR for further consideration. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#94>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAcA3WMJ188Y5yG2wPV3s21-dOF3Xzeks5rDadmgaJpZM4LAaWA> .

[Jonathan Hall]

I see the utility of this function, but like other similar requests for
wrapping errors if they haven't already been wrapped etc, or only wrapping
if haven't been annotated in a particular I'm wary because the logic is
subtle and the result of errors.StackTrace(err) would work for you, but I'm
sure someone else would want a single different version.

That's a fair criticism. Thanks for considering.

[Dave Cheney]

I dobt want you see this as a criticism, just my caution that, looking at the history of the issues raised in this repo, many people have different requirements for how they want to report their errors, what detail, how and where they want stack traces recorded, and how this is reported. There is no one size fits all option, save providing only the bare building blocks, and the only other option I see are to arbitrarily pick one way to record and represent error, or provide a flotilla of helpers to attempt to address all requirements. Neither of those sounds feasable.

…

On Thu, 1 Dec 2016, 08:15 Jonathan Hall ***@***.***> wrote: I see the utility of this function, but like other similar requests for wrapping errors if they haven't already been wrapped etc, or only wrapping if haven't been annotated in a particular I'm wary because the logic is subtle and the result of errors.StackTrace(err) would work for you, but I'm sure someone else would want a single different version. That's a fair criticism. Thanks for considering. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#94 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAcA6g2E9Xw_PZ-Ldy146oSEgES0Fgbks5rDedYgaJpZM4LAaWA> .

[Jonathan Hall]

Don't worry; I didn't mean it in the negative sense, and I don't take it personally. I do prefer a lean library, too. And it's quite true that someone may not always want just a single stack trace, or the same stack trace I find interesting. These are things made more apparent as I read other open issues, after having written my proposal earlier today.

[Dave Cheney]

Feel free to leave this issue open if you would like. I realise there is a missing piece in the error stack handing story, but I'm cautious about adding the obvious helper function that would solve one facet of the problem and make it harder to address another fascet. Id rather punt on these until some more fundamental realisations occur to me that will help me unify the various requests for when and how many stack traces are annotated to an error. It's also worth noting that while this paxkage uses semantic versioning, the go tooling ecosystem is pretty unprepared to handle this, so in effect any api added is forever. This is another reason for caution.

…

On Thu, 1 Dec 2016, 08:23 Jonathan Hall ***@***.***> wrote: Don't worry; I didn't mean it in the negative sense, and I don't take it personally. I do prefer a lean library, too. And it's quite true that someone may not always want just a single stack trace, or the same stack trace I find interesting. These are things made more apparent as I read other open issues, after having written my proposal earlier today. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#94 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAcAx_7sVdc9S0jmnsG2go_Evjqm5EVks5rDelXgaJpZM4LAaWA> .

[Jonathan Hall]

I think your caution (and that of the Go project in general) is well warranted, and wise.

If you feel there's value in leaving it open, please feel free to re-open it.

For my part, the implementation is already done in the packages where my team needs it, so I'm willing to consider the case closed.

[Steven E. Harris]

I'd appreciate a collection of add-or "recipes" like this one—things that can be layered on top of the core package, and hence don't need to be part of it, but that will likely be useful to many people. I don't think Dave wants a contrib directory here. Perhaps some gists to which we can link?