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.