Manejo centralizado de errores

Un manejador centralizado evita que cada controlador invente un formato distinto y permite ocultar detalles internos. En una API de reservas, un error de dominio como “cupo completo” puede exponerse con un código estable, mientras que el mensaje de una excepción de base de datos debe quedar en los registros del servidor, no en la respuesta pública.

Ejemplo resuelto

Un controlador puede ejecutar next(new Error('CUPO_COMPLETO')). El middleware final recibe (err, req, res, next), identifica ese código y responde 409 con { "error":"CUPO_COMPLETO" }. Para un error desconocido responde 500 con { "error":"INTERNAL_ERROR" }; el detalle se registra internamente sin incluir credenciales ni consultas.

Pruébalo

1. Define errores conocidos con código y estado.

2. Pasa errores asíncronos al flujo central. En Express 5, una Promise retornada que rechaza llega automáticamente a next; los errores dentro de callbacks ajenos necesitan pasarse explícitamente. Consulta la versión de tu proyecto antes de aplicar el patrón.

3. Coloca el middleware después de todas las rutas. Si res.headersSent ya es verdadero, delega con return next(err) en vez de intentar enviar otro JSON.

4. Envía un caso de conflicto y uno inesperado controlado.

Error frecuente: llamar dos veces a res.json. Corrígelo retornando después de responder y dejando una sola capa responsable del formato final.

Comprueba tu resultado

El cupo completo produce 409 y el código estable. El caso inesperado produce 500 sin trazas ni mensajes de base de datos. Cada solicitud recibe una única respuesta y el registro interno conserva suficiente contexto para depurar.