I have a situation where I need to discriminate between a HttpError raised by Koa (or any middleware) as opposed to any other type of error raised by the application - the latter should never occur if everything is correct, however the former is expected.
At the moment, I have a block of code like so:
import createError from "http-errors"
export async function errorHandler(ctx, next) {
try {
await next()
} catch (err) {
if (err instanceof createError.HttpError)
// this type of error is expected, should produce minimal logging
else
// create an alert for this type of error, since it should never occur in normal operation
}
}
This works, but I don't think it's ideal. The issue is that my project does not depend on the http-errors library directly; only in so far as these errors are raised by Koa when I call the throw or assert functions in a handler. I would prefer if I could handle this case by interacting with some aspect of Koa - if Koa delegates that to http-errors or some other library, I think that should be an implementation detail for Koa rather than meaning I need to introduce a library for this into my code.
So, this leaves me with two questions:
+1
I think you raised a fair point (pun intended).
It makes sense to be able to destruct from library, e.g. const { HttpError } = require('koa').
i'm not sure why you even bother to do this. i would check the error's status code and only log if it's 5xx or unknown. the type of error object shouldn't be relevant
ex.
const status = ctx.status = err.status || 500
if (status >= 500) console.error(err.stack)
ctx.body = { message: status > 500 ? 'some generic error message' : err.message }
@jonathanong Because I have several different types of errors being created in different places, each contain a status code.
I can potentially identify that an error is not type A or B (where these are non-koa errors) by looking for discriminating properties, but this seems like a poor solution when I don't care about discriminating between those types of error. I specifically care about the errors raised by koa and need to treat them separately.
Any update or solution for this item??
@RukaiYu there's a solution for this at #1159 but waiting to be merged. Given how long it has been sitting there, I wonder if that may not happen.
In the meantime, you _can_ import HttpErrors as a transitive dependency without explicitly declaring it in your package.json. However that doesn't stop any minor changes to koa breaking your code and your IDE may well complain about the import of a package that you haven't declared a direct dependency on.
I have the same problem. I need to know which error is an HTTP error and which error is another error.
Any updates on this?虋虉 I have the exact same problem here :-(
This is resolved per #1159. I think we can close this bug.
Landed https://github.com/koajs/koa/commit/2d1c5981869e0fe6f5bc71b5c5582accfd125cc6 released with Koa 2.9
Most helpful comment
@jonathanong Because I have several different types of errors being created in different places, each contain a status code.
I can potentially identify that an error is not type
AorB(where these are non-koa errors) by looking for discriminating properties, but this seems like a poor solution when I don't care about discriminating between those types of error. I specifically care about the errors raised by koa and need to treat them separately.