Add context to ErrorHandler

[pebo]

In order to correlate custom ErrorHandler logging with requests if would be very helpful if the ErrorHandler signature was expanded to include context.Context e.g.

type ErrorHandler func(ctx context.Context, w http.ResponseWriter, message string, statusCode int)

This however is a breaking change so another option could be to expand Options with a ErrorHandlerWithContext field.

[pebo]

Added two example PRs for this.

Ran into the missing context when migration to chi from gin which has a context in the validation middleware:

type ErrorHandler func(c *gin.Context, message string, statusCode int)

[mikeschinkel]

There is definitely a need for more info in the error handler.

Context is one such need, but the current matched Route, the Request, and the Request's Headers — like Accept — are others.

I created a PR (#15) that (I think) addresses @pebo's use-case in this issue but also addresses others, and in a manner that will allow adding other info if such info is found to be needed by others in the future. Hopefully PR #15 can supersede PRs #13 and #14 since they change error handling but don't address the use-cases that #15 address.

[MattiasMartens]

Would love to see this merged! Seems it's waiting on a review from the maintainer.

[tmzane]

+1 for this feature.

I agree with @mikeschinkel that it should be not just the context.Context but the whole http.Request. It'd be also really useful to have access to the original error instead of just message string, to be able to match it with errors.Is/As. My use case is to ignore ErrPathNotFound/ErrMethodNotAllowed returned by the FindRounte method. Currently, we have to match the string, which is not perfect.

So I propose the new signature to be:

type ErrorHandler func(r *http.Request, w http.ResponseWriter, err error, statusCode int)

What do you guys think?

[mikeschinkel]

@tmzane — Definitely agree that having the original error could be useful. But changing the ErrorHandler signature would break existing code so I am not a fan of that.

Have you looked at PR #15? I could see it added to ErrorHandlerOpts if #15 is accepted to resolve this PR, #14, my issue (#15) and your issue with error.