-
Notifications
You must be signed in to change notification settings - Fork 130
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
How should we handle errors on manual requests? #83
Comments
Fair point. It's been requested in #51 that the manual fetch function returns the promise, which makes sense to me because if you do a manual fetch you may also want more control about what happens when the promise resolves/rejects. But this also means that if there's a rejection and you're not interested into it you need to swallow it somehow. Unfortunately I don't see a solution that can cover both cases. Ideas? |
I thought it might be a deliberate design choice. It can be quite nice to get the actual promise. I guess you could pass in another option like this:
There is no need to over complicate this for me, at the moment I am using:
|
I guess the additional configuration option is one possible way but it doesn't feel like it deserves so much attention at the current time, I would like to keep things simple. If there's demand for this feature I may reconsider it. Thanks for reporting though! |
I might just do this
|
Or just catch the promise in a standard way.... Thanks again for the library. |
Thanks for the library!
I have a question around this example:
If there is an error calling
executePut
then we could end up with the following errorThis does not show if I use
I was not expecting an error to be thrown, as the hook sets the error. Is this how I should handle this error, or am I doing something wrong?
The text was updated successfully, but these errors were encountered: