jaydenseric
commented
4 years ago It depends what you are trying to do. You can either try to throw errors the way you need at the original place the error is thrown, try to customize errors before they get to the errorHandler middleware, or customize the response after all that has happened.
Here is an example of the latter:
// …
async (ctx, next) => {
await next();
if (ctx.response.body?.errors)
ctx.response.body.errors.forEach((error) => {
// Add an extension…
if (!error.extensions) error.extensions = {};
error.extensions.foo = 'foo';
// Reword messages…
switch (error.message) {
case 'Internal Server Error':
error.message = 'Something is wrong on our end. Sorry!';
}
});
},
errorHandler(),
// …The upside to this is you can let the errorHandler do most of the work, and you can be sure that you are having final say what is going to the client.
The downside is that while iterating the errors, you don't have the original error instances to work with - only what is intended to be exposed to the client.
An idea if you need to customize the errors before they pass through the errorHandler middleware, you could do something like this:
// …
errorHandler(),
async (ctx, next) => {
try {
await next();
} catch (error) {
// Customize the error…
// Then throw it again.
throw error;
}
},
// …A few potential gotchas with that:
- The
errorHandlermiddleware emits the error on the Koa app instance. If you are listing for errors that way for logging, you will be logging the customized error instead of the original. For example, you might need to do some gymnastics to preserve the original trace, I'm not sure. -
There are 2 main kinds of errors the
errorHandlerdeals with:- A special error that the
executemiddleware may emit if there are GraphQL errors, it has agraphqlErrorsproperty that's an array. Note that there are 3 variations of this, depending on the HTTPstatusproperty:- 5xx indicates it's a validation error with the schema on the server.
- 4xx error if it's a GraphQL validation error from the client.
- 200 if it's an error that was thrown in GraphQL resolvers.
An
extensionsproperty on the main error will have no effect, but individual errors in thegraphqlErrorsarray can have such a property that will be exposed to the client. I just tried it, and it seems theextensionsproperty ofGraphQLErrorinstances are read only - so they can't be customized in place after the error is already thrown, e.g. in Koa middleware.- Every other error. An
extensionsproperty on these errors will be exposed to the client.
- A special error that the
Regarding your first use case for a format error API:
translate
Internal server errormessage to other language
You could probably get away with the switch example I shared above; but if you needed to internationalise dynamic error message coming from resolvers that were deliberately exposed to the client then another approach would be better. You have to deliberately mark the error for exposure to the client in resolvers anyway, so at that time you could be creating the translated message. No custom Koa middleware needed.
Regarding your second use case:
catch internal db error, expose it with a nice message
Those sorts of errors IMO are best customized at the point of failure. I do things like this in my resolver code:
try {
response = await fetchTimeout(
`https://blockchain.com/tobtc?currency=${currencyCode}&value=1`
);
} catch ({ message }) {
throw new Error(
`Failed to fetch Bitcoin price for currency code “${currencyCode}” using Blockchain: ${message}`
);
}Note that I'm making a nice message for my API error log, but deliberately these sorts of resolver errors should not be exposed to the client — the errorHandler middleware will mask them with an Internal Server Error message. What goes wrong in your backend is none of their business. In development, you should look at your API process to see errors logging; don't rely on looking at errors on the client side to debug problems with your server.
I could see how maybe a formatError option for the errorHandler middleware would make some edge-case situations easier, it would accept a function:
function formatError(errorOriginal, errorExpose) {
// Return the object to be JSON stringified in the response body `errors` array.
// `errorExpose` is what would have been exposed by default.
return errorExpose
}Given the above discussion, do you really need it?
vladshcherbin
It would be nice to be able to reformat error in
errorHandler. It's useful when you need to modify error before sending to client, for example:Internal server errormessage to other languageThe api might be as simple as:
I keep hitting this actually simple cases where I just want to format my errors before sending them to client and current
errorHandleris too restrictive in what I can do. However, I'm trying to avoid writing custom middleware instead oferrorHandlerand struggling to find solutions.@jaydenseric help 🙏