Skip to content

feat: add new error handler func with context parm #14

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

Closed
wants to merge 1 commit into from

Conversation

pebo
Copy link
Contributor

@pebo pebo commented Feb 14, 2024

Add ErrorHandlerWithContext func to options. If both ErrorHandler and ErrorHandlerWithContext are set the later takes precedence.

Shows alternative fix for #11

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
Add ErrorHandlerWithContext func to options. If both ErrorHandler
and ErrorHandlerWithContext are set the later takes precedence.
@pebo pebo requested a review from a team as a code owner February 14, 2024 20:50
@mikeschinkel
Copy link
Contributor

mikeschinkel commented Apr 24, 2024

@pebo — See any reason it should be limited to r.Context and not instead just pass in r?

I came here today because I need access to r.URL and r.Method so I can determine what content type I should return for the response.

Also, come to think of it, validateRequest(r *http.Request, router routers.Router, options *Options) should really also return the route that it matches, and then pass that to the error handler as well. Otherwise I'll have to maintain hard-coded information in my custom error handler that is already in openapi.yaml` file and should really only need to be here.

Would love to hear from the project owner if they will consider these or not.

@pebo
Copy link
Contributor Author

pebo commented Apr 25, 2024

@pebo — See any reason it should be limited to r.Context and not instead just pass in r?

I came here today because I need access to r.URL and r.Method so I can determine what content type I should return for the response.

Also, come to think of it, validateRequest(r *http.Request, router routers.Router, options *Options) should really also return the route that it matches, and then pass that to the error handler as well. Otherwise I'll have to maintain hard-coded information in my custom error handler that is already in openapi.yaml` file and should really only need to be here.

Would love to hear from the project owner if they will consider these or not.

I just needed the context and IIRC this is how the other middlewares worked. As for project owner, @jamietanna any chance this could be considered?

@mikeschinkel
Copy link
Contributor

mikeschinkel commented Apr 25, 2024

@pebo — Thank you for the quick reply.

I submitted an alternate PR (#15) where I tried to address your use-case, as well as address mine too. Hopefully it will meet your needs instead?

You can clone it from here and use a go.work file to see if it meets your needs.

-Mike

@jamietanna
Copy link
Member

Thanks all for the patience and suggestions - I'm looking at getting this tackled via #35 - please take a look at the signature and let me know thoughts

(This will be merged in the next couple of days, and anyone who's contributed suggestions will get a Co-Authored-By in this change, so even though it won't show as a "merged PR" from you, it'll definitely show as you having contributed to the work!)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants