assert(): una guía moderna para dominar la aserción en código
Assert(): A Modern How To
El autor Reza Naghibi defiende el uso de assert() como pilar del software correcto y seguro, pero critica las implementaciones limitadas y la confusión sobre cuándo usarlas. Propone cuatro áreas de aplicación: corrección, seguridad, desarrollo y documentación. Explica cómo las aserciones garantizan la cobertura total de valores, previenen desbordamientos y accesos inseguros, y sirven como documentación ejecutable. Además, sugiere una API ideal con aserciones de producción y desarrollo, mensajes dinámicos y volcado de pila.
Una aserción fallida se comporta exactamente como pretendías: capturó correctamente un caso límite.
- foo42
Una técnica que se solapa (cubriendo algunas pero no todas las circunstancias en las que usarías assert) es adoptar un enfoque de parsear-no-validar, y esencialmente codificar en el tipo el hecho de que se ha aplicado una aserción a un valor.
Lo ergonómico que esto sea variará según el lenguaje, pero la idea general sería aplicar la lógica de aserción en algún tipo de constructor, y luego prevenir cualquier operación que pudiera romper el invariante en el futuro. La forma más simple de proteger esto es haciendo que el valor sea inmutable cuando sea posible.
Los usuarios del valor que se preocupan de que el invariante sea verdadero pueden entonces especificar en sus tipos que quieren una colección no vacía o un id de foo o lo que sea, en lugar de pedir el tipo más amplio y luego hacer la aserción.
- iTokio
Me encanta combinar las aserciones con la «reiniciabilidad».
Si tu programa ha entrado en un estado desconocido o fallido, simplemente reinícialo desde un estado conocido.
Mejor aún si puedes dividir un sistema complejo en submódulos que puedan recuperarse de forma independiente sin derribar todo el sistema.
Algo como el árbol de supervisión de Erlang. O al menos un servicio con systemd Restart=always.
Si tu programa es mayormente sin estado y «reiniciable», se vuelve tolerante a fallos, y puedes usar aserciones liberalmente y evitar fácilmente estados desconocidos o malos.
Los invariantes pueden ser aplicados, y la corrección preservada.
Pero queda una pregunta importante cuando se dispara una aserción: ¿por qué se violaron los invariantes?
Necesitamos preservar el contexto y decidir si manejar o no este caso.
Eso es fácil de olvidar en código orientado a aserciones.
- eps
> ¿Se pueden usar aserciones en producción?
Sí
> ¿Sobre qué debería hacer aserciones?
Invariantes
> ¿Puedo personalizar cómo se comporta assert?
Debería abortar el programa, registrando la pila y cualquier contexto que le pases, al estilo printf. Si no aborta, solo entierra el problema de que el programa está en un estado interno incorrecto. Nunca debería estar bien.
- oso2k
Es interesante que el autor llegue a una API muy similar a la firma de función de TAP (Protocolo de Prueba de Cualquier Cosa).
ok( condicional, mensaje );
- dicroce
Personalmente no soy muy fan de los assert()... al menos en el lenguaje que más uso (C++). No es que no piense que deberías validar los rangos de entrada de los parámetros de las funciones, es que en general las excepciones son mejores.