Middleware for error handling

[j-d-carmichael]

https://github.com/acr-lfr/generate-it-typescript-server/blob/master/src/http/nodegen/middleware/handleHttpException.ts#L17

I want to be able to pipe all errors to a handler that I control.. maybe to send the error to a 3rd party, for example, alert instantly when a 500 happens opposed to relying on something like new relic which does have a bit of a delay.

Off the top of my head, something like https://github.com/acr-lfr/generate-it-typescript-server/blob/master/src/services/PermissionService.ts

A file that is omni-present and does nothing unless you mess with it..

The PR #197 is the idea, in the PR the dev now has control over how to handle the 500 errors and is given the option to inject adhoc 500 error warnings via API calls, emails or pigeons if needed.. or whatever other creative concept comes to mind.

@p-mcgowan @zewish @acrontum-sanchez

[p-mcgowan]

Yeah I rmember doing the userland <-> genland back in the day, something about formatting the error for tne same reason.

I'll find the solution we implemented in another project - basically we just popped out the auto loader from the bootstrap and wired up a few more handlers as we couldnt do it flexibly otherwise.

PR looks promising though, maybe we can merge the two concepts into something if it means something really cool

[p-mcgowan]

note - we did something like this a while back and decided to undo it (I believe sometimes logs didn't show up?):
https://github.com/acr-lfr/generate-it-typescript-server/pull/33/files#diff-779ab0fb0b89bb96497559084b14ad4d4d650bd6519dc2f01527d216a7e260a3R25

But same principle - instead of calling format on serialization, we could stub the middleware into userland, call if from the app, and just allow it to get fully overwritten.

If it's a stub, the default handler in the stub should call back to some auto generated middleware applying method - then we don't end up with userland getting out of sync with generated code

[j-d-carmichael]

OK so this discussion is closed for now - a pr was merged in that allows a dev to inject and override the catch-all exception handler which allows custom error handlers to intervene where required.. eg db, 500's etc etc. The last general catch-all is still there should any of the custom handlers fail to catch:

https://github.com/acr-lfr/generate-it-typescript-server/blob/master/src/http/index.ts#L53

[p-mcgowan]

Just a note: it's possible to completely override the default error handler (as you mentioned) by always resolving the request (eg res.end('nope')), but it also allows for injecting custom error handling logic in addition to allowing the default error handler to still catch all errors.

[zewish]

@p-mcgowan, you're falling back to plain node streams here. I'm pretty sure you'll be doing something crazy in order to do this, which would mean you already know what you're playing with.

[p-mcgowan]

lol - old habit, but yeah that's actually very misleading..

What I meant to say, is that if you inject custom error handling and call express' res.status(200).json({ msg: 'what error?' }) instead of callign the next handler with an error next(error), then you are skipping the default catch-all error handler middleware that applies when no others handle the error:

// example of handling specific error, but passing others to handleHttpException.ts
export const myCustomErrorHandler = (err: HttpException, req: NodegenRequest, res: express.Response, next: express.NextFunction) => {
  if (!(err instanceof MyCustomError)) {
    return res.status(418).json({ message: err?.message, explaination: 'teapot' });
  }

  return next(error);
}

// example of using custome error handling to override (or skip) the default handleHttpException.ts
export const myCustomErrorHandler = (err: HttpException, req: NodegenRequest, res: express.Response, next: express.NextFunction) => {
  console.error(err.stack || err);

  if (err.status === 500 && config.env === 'production') {
    return res.status(err.status).json({ message: 'Internal server error' });
  } else {
    return res.status(err.status).json(err);
  }

  // no next called, the global exception handler is never it
}