`Errorf` should be able to wrap errors

[osamaadam]

I expected Errorf to mimic fmt.Errorf's behavior of wrapping errors. Alas, that was not the case.
I was wondering if this is intentional or not. If it's intentional, then is there a way of formatting wrapping errors as '(wrapped error): outer error'?

Here's a playground link explaining what I'm talking about.
https://play.golang.org/p/yDjjs_8GsSY

[puellanivis]

The package predates the error wrapping functionality of fmt.Errorf and thus consideration for how to integrate the functionality of wrapping errors with Errorf("… %w", err) was not something that could have been considered at the time. Then when fmt.Errorf did start wrapping errors, a large amount of this package became redundant, and so the package has since seen less attention and utility.

If we did update the errors.Errorf to work the same as a fmt.Errorf then it should still abide by the same conditions that fmt.Errorf does, that is, the %w verb can only occur at the end of the formatting string. Howver, since we provide the Wrap() WithMessage and WithStack functions, adding utility of Errorf to wrap errors doesn’t seem altogether too useful, except only for aligning usage between the two.

[osamaadam]

Okay so bear with me as I only started dabbling in Go about a month ago or so. I didn't know about the restriction that %w has to come at the end of the formatted string. I've checked the fmt docs, but there seems to be no mention of this particular restriction. The only restriction there seems to be on fmt.Errorf is that there may only be at most one %w within the formatted string.

The main reason I'd be interested in Errorf wrapping errors is because I like to use the error pattern of fmt.Errorf("%w: extra details", baseErr). errors.Wrap(baseErr, "extra details") produces "extra details: baseErr" which I'm not used to but it seems to be the canonical way of wrapping errors in Go.

I could look into making a pull request to add this Errorf wrapping behavior, but it seems there won't be many use cases for this besides the one I mentioned.

[davecheney]

produces "extra details: baseErr" which I'm not used to but it seems to be the canonical way of wrapping errors in Go.

yup, the usual form is 'outer most: outer: inner: inner most'

[puellanivis]

Huh, it seems the caveats about errors needing to be the last argument to Errorf appear to be from the original xerrors and I never updated my mental information on it, because I never thought to do anything other than "added context: %w"