Koa: HttpError handling

Created on 9 Mar 2018  路  11Comments  路  Source: koajs/koa

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. Is this the appropriate way to handle this situation, or is there some other mechanism I should be using?
  2. If this is the correct way to handle this case, can Koa export the errors in use from other libraries?

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 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.

All 11 comments

+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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ke1Del picture ke1Del  路  3Comments

edahlseng picture edahlseng  路  3Comments

xinshouke picture xinshouke  路  4Comments

tvq picture tvq  路  4Comments

dounine picture dounine  路  4Comments