-
-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ErrorHandlerWithOpts
#15
base: main
Are you sure you want to change the base?
Conversation
type ErrorHandlerOpts struct { | ||
*http.Request | ||
*routers.Route | ||
context.Context |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding a field here error
to capture the original error would be helpful (cf: #11 (comment))
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MattiasMartens — Thank you for that suggested change. Assuming I understood your suggestion then I think it is an excellent idea. Actually, disappointed in myself for not thinking of it initially.
I made that change to the PR. Please review the PR to make sure I correctly understood what you were suggesting.
if statusCode, route, err := validateRequest(r, router, options); err != nil { | ||
if options != nil { | ||
if options.ErrorHandlerWithOpts != nil { | ||
options.ErrorHandlerWithOpts(w, err.Error(), statusCode, ErrorHandlerOpts{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If change to ErrorHandlerOpts
is implemented then we could add here:
options.ErrorHandlerWithOpts(w, err.Error(), statusCode, ErrorHandlerOpts{ | |
options.ErrorHandlerWithOpts(w, err.Error(), statusCode, ErrorHandlerOpts{ | |
Error: err, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I made that change to the PR. Please review the PR to make sure I correctly understood what you were suggesting.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Thanks guys. Also looking for such functionality. |
This PR adds an alternate custom error handler with an additional
opts
parameter that allows a custom error handler access to the incoming*http.Request
, then matchedroutes.Route
, and the relevantcontext.Context
.My use-case for why the Route is needed is to be able to determine the appropriate Content-Type for an error response; should it be
application/json
,text/html
or something else?I added
Request
as I originally thought I would need it, but I didn't. Still, I can easily see that others might so it doesn't seem a harm to provide it.I added
Context
to explicitly fulfill the use-case for #13 & #14, and hopefully to supercede them.Lastly, I chose an
opts
parameter passing inErrorHandlerOpts
so that future needs could be accommodated easily by just adding a property without needing to add yet another signature and yet another type of error func.P.S. I also had to modify private function
validateRequest()
to get it to return the matchedrouters.Route
— as well as that that called it — given that access to theRoute
was the motivation for this PR.