intermediate

Express error middleware

Преобразуйте thrown, rejected, validation, domain и unknown errors в stable HTTP responses без потери diagnostic context.

Error-handling middleware имеет четыре параметра `(err, req, res, next)` и регистрируется после всех routes и middleware. Express направляет thrown errors и `next(err)` в эти handlers.

					app.use((err, req, res, next) => {
  const status = err.statusCode ?? 500;
  const body = err.isOperational
    ? { error: err.message, code: err.code }
    : { error: 'Internal server error' };
  logger.error({ err, requestId: req.id });
  res.status(status).json(body);
});
				

Классифицируйте ошибки: validation (4xx), auth (401/403), domain conflicts (409), unknown (500). Operational errors — безопасные сообщения клиенту; programmer errors — stack в логах, не в response.

На интервью: зачем async route errors нужны wrappers, как сохранить `requestId` в логах и стабильный error shape для API clients.

Типовые ошибки: один generic handler без классификации, stack traces в production, отсутствие error middleware — async failures зависают или роняют процесс.

Компромисс — между простотой, производительностью, безопасностью и эксплуатацией: назовите, что оптимизировали и какую цену приняли.

Чеклист:

  • Error middleware регистрируйте последним.
  • Разделяйте operational и programmer errors.
  • Единообразный map domain errors → HTTP status.
  • Контекст в логах; санитизация client responses.