Errores, status codes y logging

Los errores deben ser útiles para el cliente y para quien opera el sistema sin revelar detalles internos. Una política sencilla asigna 400 a entradas inválidas, 401 a ausencia de autenticación, 403 a permisos insuficientes, 404 a recursos inexistentes y 500 a fallos no previstos.

Ejemplo resuelto

Si GET /courses/c9 no encuentra registro, responde 404 con un código como COURSE_NOT_FOUND. El log interno puede incluir método, ruta, identificador de petición y duración, pero no una contraseña ni un token. Si la base de datos falla, el cliente recibe un mensaje genérico y el log conserva el contexto operativo permitido.

El manejador de errores conserva sus cuatro argumentos y se registra al final:

app.use((err, req, res, next) => {
  if (res.headersSent) return next(err);
  if (err.type === 'entity.parse.failed') {
    return res.status(400).json({ error: 'INVALID_JSON' });
  }
  if (err.type === 'entity.too.large') {
    return res.status(413).json({ error: 'BODY_TOO_LARGE' });
  }
  return res.status(500).json({ error: 'INTERNAL_ERROR' });
});

Express 5 pasa al manejador los rechazos de una promesa devuelta por una ruta asíncrona. Errores en callbacks externos requieren propagación explícita con next(err); no se capturan por existir una función async en otro lugar. Registra internamente el ID y contexto permitido antes de responder, sin imprimir el body entero.

Pruébalo

1. Crea una tabla de escenarios y status esperado.

2. Usa un error centralizado para formar respuestas.

3. Añade un identificador de petición al log.

4. Revisa que los secretos no aparezcan en ninguna línea.

Error frecuente: devolver el mensaje de una excepción de base de datos. Corrígelo con un mensaje público estable y un detalle interno controlado.

Comprueba tu resultado

Verifica tres casos: body inválido produce 400, curso inexistente 404 y excepción simulada 500. En los tres logs debe existir método y ruta; en ninguno debe aparecer una credencial.