Can caddy v2 caddyhttp.HandlerError add Unwrap method?

[yflau]

I think it’s best for caddyhttp.HandlerError to add Unwrap method to provides compatibility for Go 1.13 error chains like this:

// Unwrap provides compatibility for Go 1.13 error chains.
func (e HandlerError) Unwrap() error { return e. Err }

Imagine a scene like this，a custom Module which arrange several caddyhttp.MiddlewareHandler, and determine the execution path according to the returned error, and then maybe wrap the returned error again, e.g.

errors.Wrap(aHandlerError, "fusion module error")

thus we can not get the HandlerError info in such way:

if handlerErr, ok := err.(HandlerError); ok {
    // ...
}

like in func (*HTTPErrorConfig) WithError and func errLogValues(err error) .
But we can always get HandlerError info like this:

var handlerErr = caddyhttp.HandlerError{}
if errors.As(err, &handlerErr) {
	// ...
}

as long as there is no missing Unwrap on error chain.

[matt (Matt Holt)]

It’s a good suggestion, but it depends on whether we want to reveal underlying errors to the exported API. My inclination for now is not to do that unless we have compelling reasons, to keep the exported API surface as small as possible. Do you have a specific need for this?

[yflau]

@matt

My inclination for now is not to do that unless we have compelling reasons, to keep the exported API surface as small as possible. Do you have a specific need for this?

For now I have no such specific need

Actually we plan to use our error hierarchy, it seemed something like this:

type APIErrorMeta interface {
	StatusCode() int
	System() string
	Code() string
	...
}

type APIError interface {
	APIErrorMeta
	error
}

In some cases，we need the advised information from underlying error. Of course we can define some idiomatic constraints, just a worry about mixing. Also I will do a conversion from HandlerError to APIError.

Thank you for reply.