error.type for wrapped errors

[pellared]

Was there any preceding discussion about detecting when the reported type is *fmt.wrapError, and calling Unwrap on it to dig down to instead report the type of the outermost error that is not a wrapping error?

(I ask this because my "error.type" attribute values are almost always winding up as the unhelpful "*fmt.wrapError".)

Originally posted by @seh in #6904

[Balaji01-4D]

Hi @pellared — I’d like to work on this issue. I have contributed earlier and would be glad to pick this up if it is available.

[MrAlias]

• How far do we unwrap?
• What is the behavior if there are multiple errors wrapped, and possibly at different levels? (i.e wrapped(wrapped(err0, err1), err2))
• What if a user wants the type to be the wrapped type to show it is a higher level error?

[seh]

I think we should publish two separate attributes for the case when the errors.Unwrap function returns a different value from its argument. You as the caller don't decide how far to unwrap; that function's implementation decides to stop when there is no next error in hand that implements an Unwrap method (or, rather, that's how the protocol is supposed to work, falling to individual implementations of Unwrap to play along).

[Balaji01-4D]

Hi @pellared and team,

Apologies for the late reply. I saw that #7994 was merged and already handles the ErrorType() interface detection across the error chain. I am picking up the remaining part about improving the reflection fallback so that wrappers like *fmt.wrapError dont end up being reported as the error type.

[Balaji01-4D]

Before opening a PR, I wanted to clarify a couple of points:

• Multi-errors (errors.Join) – Since errors.Unwrap(err) returns nil for multi-errors (they implement Unwrap() []error), the loop would stop there and report the multi-error type itself. Is that acceptable or handle explicitly?
• Separate attributes – @seh previously mentioned possibly publishing separate attributes (wrapper + root). Should this change only adjust the existing attribute to report the concrete underlying error type?

func errorType(err error) string {
	 // ... existing code ...

	if s == "" {
		curr := err
		for {
			if u := errors.Unwrap(curr); u != nil {
				curr = u
			} else {
				break
			}
		}

		t := reflect.TypeOf(curr)
		pkg, name := t.PkgPath(), t.Name()
		if pkg != "" && name != "" {
			s = pkg + "." + name
		} else {
			s = t.String()
		}
	}
	return s
}

If this direction looks correct, I will go ahead.

[pellared]

@Balaji01-4D, please also look at open-telemetry/semantic-conventions#3503. I think this is not only a problem in Go.

[aldas]

just one note here - what is the intention of getting that "error type"? Is is used to deduce something? Most of the time in Go you wrap errors to establish something like to stacktrace and sometimes join errors just to combine different "problems" to more generic result (like join multiple request payload validation errors).

So when you start to unwrap errors then the bottom/deepest error could be the same "type" that the other error which has absolutely different "path". Ala file io related errors - http.Request.MultipartForm.File related method could return fs.ErrNotExist or the same fs.ErrNotExist would be returned from your handler specific code (serving jpg from disk). These may be the same unwrapped type but could mean completely different things to observer.

[seh]

Those are fine counterexamples, Martti, but clearly *fmt.wrapError is not useful information to receive when trying to categorize or find a particular failure. Not all error-implementing types implement an Unwrap method. Some wrapping types are meant to be peeled away because they don't represent anything material, such as those that exist just to manipulate callers' behavior, such as backoff.PermanentError, per the recent cenkalti/backoff#178.

I have an error type that communicates a recommended exit code for the containing process. There are analogous ones to convey a recommended HTTP status code. Those are the sorts of types that I want to peel away. They implement Unwrap as a way of indicating that they don't mean to stay in the way.

Before we canonized errors.Unwrap, there had been Causer interface types, and some of the modules that still bear them distinguish them from Unwrap, and some do not, the latter treating Cause as a deprecated alias for Unwrap.