Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

Proper way to get more data in catchers #2462

Closed
TPausL opened this issue Feb 4, 2023 · 1 comment
Closed

Proper way to get more data in catchers #2462

TPausL opened this issue Feb 4, 2023 · 1 comment
Labels
suggestion A suggestion to change functionality

Comments

@TPausL
Copy link

TPausL commented Feb 4, 2023

Existing Functionality
I want to pass details to catchers. From a Guard there is the request.local_cache, which works but is sometimes error prone to set up as it has to typed correctly on both ends (setting and retrieving) and has to wrapped by an option. But the main problem with that is that there is no way of setting it within a request handler itself. I for example validate my incoming data in a request guard but then store it in the database later in the request handler. If that fails i can only manullay return an error instead of say passing a string and then sending a generic response with that custom message, which would reduce code duplication.

Suggested Changes
some way to store data in the request more conveniently, which is accesible from every part of the code touching the request somehow.

Alternatives Considered
being able to write to the request local_cache within request handler

Additional Context
if you want to have a look at my code in order to understand the problem better or suggest better ways feel free to take a look:
TPausL/power-music-backend

@TPausL TPausL added the suggestion A suggestion to change functionality label Feb 4, 2023
@SergioBenitez
Copy link
Member

What we eventually want is #749, and it's something I intend to work in soon™. I think that would resolve your issue? I'm not sure I totally understand the motivation behind it.

I for example validate my incoming data in a request guard but then store it in the database later in the request handler. If that fails i can only manullay return an error instead of say passing a string and then sending a generic response with that custom message, which would reduce code duplication.

Why can't you place the error in request-local cache in the request guard implementation?

I'm converting this into a discussion, assuming #749 would indeed be the desired fix.

@rwf2 rwf2 locked and limited conversation to collaborators Mar 28, 2023
@SergioBenitez SergioBenitez converted this issue into discussion #2508 Mar 28, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
suggestion A suggestion to change functionality
Projects
None yet
Development

No branches or pull requests

2 participants