Cuál es la estrategia si falla la aserción

Question

La aserción se utiliza para verificar si se cumple una condición (precondición, condición posterior, invariantes) y ayudar a los programadores a encontrar los agujeros durante la fase de depuración.

Por ejemplo,

void f(int *p) 
{ 
    assert(p); 
    p->do(); 
} 

Mi pregunta es qué tenemos que asumir la condición no se pudo cumplir en el modo de disparo y manejar el caso en consecuencia?

void f(int *p) 
{ 
    assert(p); 

    if (p) 
    { 
    p->do(); 
    } 
} 

Después de todo, la afirmación significa que la condición que prueba NUNCA debe ser falsa. Pero si, si no lo verificamos y falla, el programa se bloquea. Suena como un dilema. ¿Cómo lidian ustedes con eso?

Answer 1

Si la afirmación falla, el programa debería bloquearse.

Una falla de afirmación significa que el programador cometió un error fundamental en su comprensión de cómo es posible que proceda el flujo del programa. Esta es una ayuda al desarrollo, no una ayuda a la producción. En producción, uno podría manejar excepciones, ya que "podrían" ocurrir, mientras que las afirmaciones "nunca" fallarían.

Si estás en el campamento que dice: "Ah, pero ¿y si las afirmaciones fallan en la producción? ¡Necesito atraparlas!" entonces te estás perdiendo el punto. Pregúntate, en tal caso, ¿por qué no lanzas una excepción (o manejas el error)?

En términos generales, afirman es no sólo una abreviatura de "si no se cumple la condición, excepción tiro" (bueno, a veces eso es la semántica operacional, pero no es la semántica denotativa). Más bien, una afirmación que falla significa que la aplicación está en , un estado que el desarrollador no cree que sea posible. ¿Realmente quiere que el código continúe ejecutándose en tal caso? Claramente (yo diría), No.

Answer 2

Las aserciones son un código de depuración, no un código de operación. No los use para detectar errores de entrada.

Answer 3

Las afirmaciones se utilizan para detectar errores en las pruebas. La teoría es que has probado lo suficiente como para saber que funcionará una vez que lo hayas liberado.

Si existe la posibilidad de que la condición surja en el funcionamiento de la vida real, no confíe en las aserciones, use excepciones u otro mecanismo de error.

Answer 4

Las afirmaciones son útiles para la depuración como mencionaste. Nunca deben entrar en el código de producción (compilado, está bien envolverlos en #ifdefs por supuesto)

Si se encuentra con un problema que no puede controlar y necesita el control en su producción código que haría algo como:

void f(int *p) 
{ 

    if (!p) 
    { 
    do_error("FATAL, P is null."); 
    } 

    p->do(); 
} 

Dónde do_error es una función que registra un error y limpiamente, sale.

Answer 5

La programación defensiva siempre es la mejor. Siempre debe suponer que, a pesar de todas sus pruebas, su aplicación se enviará con errores.Como tal, le conviene agregar comprobaciones NULL en situaciones en las que puede evitar una deferencia de puntero NULL y simplemente seguir adelante.

Sin embargo, hay situaciones donde simplemente no hay una manera fácil de evitar un bloqueo, y en esos casos, la afirmación es su única forma de detectar el problema durante su ciclo de desarrollo.

Sin embargo, un punto importante, afirma, también se utiliza para detectar problemas importantes con la integridad de sus datos. Si continúa más allá de esos asertos, puede arriesgarse a corromper los datos. En esos casos, puede ser mejor bloquear en lugar de destruir sus datos. (Obviamente, cualquier tipo de controlador de fallos que al menos muestra una interfaz de usuario razonable con una descripción de error sería preferible).

Answer 6

Digo déjalos en la versión de lanzamiento. Es probable que haya errores en cualquier compilación. Tener afirmado en su producto significa que puede identificar el problema más fácilmente cuando recibe un informe de problema de un usuario.

No ponga mucho esfuerzo en el manejo de las excepciones. Simplemente asegúrate de que puedes obtener la excepción completa, incluido stacktrace. Eso se aplica a la versión de lanzamiento en particular.

Answer 7

Estrictamente hablando, el segundo código tiene redundancia.

void f(int *p) 
{ 
    assert(p); 
    if (p) // Beats the purpose of assertion 
    { 
    p->do(); 
    } 
} 

Se ha producido un error de aserción. Algo que es inesperado/no controlado. En el código anterior, ya sea

1) Usted está manejando adecuadamente el caso donde p es nulo. (No llamando a p-> do()), que supuestamente es lo correcto/esperado. Sin embargo, entonces la afirmación es una falsa alarma .

2) Por otro lado, si al no llamar a p-> do(), algo irá mal (tal vez más en el código o en el resultado), entonces la afirmación es correcta, pero no debería haber ningún punto en continuar de todos modos.

En el código anterior, el programador está trabajando muy duro para manejar casos que son erróneos de todos modos.

Dicho esto, a algunas personas les gusta tratar aseveraciones como , algo salió mal, pero veamos si todavía obtenemos la salida correcta. OMI, esa es una mala estrategia y crea confusiones durante la corrección de errores.

Answer 8

Dado que muchas personas están comentando poner afirmaciones en modo de lanzamiento:

En lo que trabajo, la eficiencia es muy importante (a veces, la ejecución de grandes conjuntos de datos tarda decenas de horas a pocos días para completar). Por lo tanto, tenemos macros especiales que solo se afirman en el código de depuración (se ejecutan durante QA, etc.). Como ejemplo, una afirmación dentro de un bucle for es definitivamente una sobrecarga y es posible que desee evitarlo en el código de lanzamiento. Después de todo, si todo está bien, las afirmaciones no deben fallar.

Un ejemplo donde los códigos de liberación son buenos es - si no se supone que la lógica llegue a una rama de código en particular. En este caso, assert (0) está bien [por lo tanto, cualquier tipo de afirmación (0) siempre se puede dejar en el código de liberación].