Excepciones que dejan la puerta abierta

Cuando la pieza que respalda un control no responde, el código tiene que elegir. Puede fallar cerrado: no deja pasar lo que no pudo comprobar y lo retiene hasta poder hacerlo. O puede fallar abierto: sigue como si la comprobación hubiera salido bien. Lo segundo casi nunca se escribe a propósito; aparece en un bloque catch que registra la falla y deja que la ejecución continúe hacia el camino feliz.

El Top 10 de OWASP de 2025 dedica su décima categoría al manejo inadecuado de condiciones excepcionales: software que no prevé, no detecta o no responde bien a lo inusual, y que por eso termina en estados que nadie diseñó. Agrupa 24 debilidades del catálogo CWE, y una de ellas es justamente no fallar de forma segura. Que un proveedor se caiga es normal; que su caída apague un control es un fallo del código.

Abre el laboratorio y lee VerificadorFormula.php y AutorizarDevolucion.php. Hay tres bloques try/catch que envuelven una llamada a un servicio externo. Para cada uno, no te quedes en lo que hace el catch: sigue la ejecución hasta lo que el método devuelve después. Dos de ellos, ante la duda, niegan o mandan a revisión humana; uno registra la falla y deja que el bucle continúe hasta un return que aprueba.

El hallazgo se mide con el registro, no con el código. En registro-despachos.txt cada línea dice si el producto exige fórmula, qué contestó el validador y qué pasó con el pedido. Cuenta los pedidos que cumplen las tres condiciones a la vez: el producto exige fórmula, el validador no llegó a responder y el pedido salió a despacho.

Un hallazgo bien clasificado le dice al equipo qué familia de errores buscar en el resto del código. Dentro de la categoría de condiciones excepcionales conviven debilidades muy distintas: mensajes de error que revelan datos, valores de retorno que nadie revisa, errores que se detectan y no se atienden, y diseños que ante la falla pasan a un estado menos protegido. La clasificación correcta es la que describe la causa, no el síntoma que se ve primero en el registro.

El cambio CS-212 resolvía un problema real: dos caídas del proveedor frenaron las ventas una hora cada vez. Pero lo resolvió quitando el control justo cuando no hay nadie que lo sustituya; la revisión del regente al final del día no está automatizada y ese sábado no hubo regente. El propio código de Siemprevida ya muestra el patrón correcto en requiereRevisionRegente y en AutorizarDevolucion: ante la duda, se reporta y se niega o se retiene. La continuidad del negocio se consigue con una cola de pedidos pendientes que se revalidan solos, no abriendo el control.