Error handling in mutations: handle HTTP 400/500 globally, and other errors case by case?
Hi, I'm trying to improve the error handling of my application but I'm lost at what the best approach is.
When I encounter a 500 response, I always want to display a generic toast message. For 400 errors something similar could be done. However, for business logic errors, I want to handle it case by case, e.g. when calling the mutation function, because the error depends on which mutation is done. In the global onError, I could check
error.statusCode >= 400 for example to display a toast message. However, this means I would have to repeat this check in every local onError handler to prevent showing a warning twice (error.statusCode < 400). There is not a way to filter/pipe errors in a certain way so they are handled by only one onError function.
Because my scenario is pretty standard for every SPA, it feels like I'm taking the wrong approach. What would be the recommended way to handle different kinds of API errors and differentiate between server/client/business errors?8 Replies
ratty-blush•3y ago
have a look at the global cache callbacks: https://tanstack.com/query/v5/docs/react/reference/MutationCache#global-callbacks
MutationCache | TanStack Query Docs
The MutationCache is the storage for mutations.
Normally, you will not interact with the MutationCache directly and instead use the QueryClient.
extended-yellowOP•3y ago
@TkDodo 🔮 Thanks for your quick response! I'm still lost though how this solves the issue. If I handle an error globally, I assume the mutation's error handler will still be called, resulting in double error handling?
ratty-blush•3y ago
yes? I guess you'd want to handle 5xx errors globally, and 4xx errors in every mutation separtely ?
so in the global cache callback, you make the 5xx check
extended-yellowOP•3y ago
I guess I'm looking at it the wrong way. I'm trying to differentiate between the errors I deliberately throw in the backend (let's say HTTP 400 response with the shape { error: string }), and any other error thrown in the backend (handled by the framework itself, with unpredictable shape). If I use the global error handler you mentioned, then in my mutations I would still have to repeat the same check, say
error.statusCode !== 400. Without this check, I can't be sure that it's a custom error with the error.error property.ratty-blush•3y ago
if you don't want to repreat the check then add the check to the global error handler. Sorry, I'm not understanding the problem, it's prettty hypotethical to me. A reproduction would help
extended-yellowOP•3y ago
I made a reproduction here: https://codesandbox.io/s/cold-http-hk5yrx?file=/src/App.js
Basically, I want the global error handler to be the only error handled if it "handled" the error, if that makes sense.
ratty-blush•3y ago
okay, I undestand. no, there is no middleware / chaining like behaviour for error handlers.
extended-yellowOP•3y ago
Alright thanks for your time. I'll look into other ways of handling errors