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

Question

aserción se utiliza para comprobar si se cumple una condición (condición previa, postcondition, invariantes) y ayudar a los programadores encontrar huecos durante la depuración de fase.

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, medios afirmación de que la condición que pone a prueba nunca debe ser falsa. Pero si, si no comprobamos y se produce un error, el programa se bloquea. Suena como un dilema. ¿Cómo ustedes tratar con él?

Answer 1

Si la afirmación falla, el programa debe chocar .

Una afirmación no significa que el programador ha cometido un error fundamental en la comprensión de cómo es posible que el flujo del programa para proceder. Se trata de una ayuda para el desarrollo, no una ayuda a la producción. En la producción, se podría manejar excepciones , ya que "podría" ocurrir, mientras que las afirmaciones deben "nunca" fallar.

Si usted está en el campo que dice: "Ah, pero lo que si fallan las afirmaciones en la producción? I necesidad de capturarlos!" entonces usted está perdiendo el punto. Pregúntese, en tal caso, ¿por qué no acaba de lanzar una excepción (o de otra manera manipular el error)?

En términos generales, aserción es no sólo una abreviatura de "si la condición no se cumple, a excepción tiro" (bueno, a veces esa es la semántica operacional, pero no es el denotacional semántica). Por el contrario, una afirmación mediante la aplicación no está en un estado del desarrollador no cree que es aún posible . ¿Desea realmente el código para continuar la ejecución en este caso, un? Claramente (diría yo), No .

Answer 2

La programación defensiva es siempre lo mejor. Siempre se debe asumir que a pesar de todas sus pruebas, su solicitud se enviará con los insectos. Como tal, es en su mejor interés para añadir controles de NULL en situaciones donde se puede evitar una deferencia puntero NULL y simplemente seguir adelante.

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

Un punto importante sin embargo - afirma también se utilizan con frecuencia para detectar los principales problemas con la integridad de sus datos. Si continúa más allá de los que se afirma, es posible que el riesgo de corrupción de datos. En esos casos, puede ser mejor para estrellarse en lugar de destruir sus datos. (Obviamente, cualquier tipo de manejador de fallos que por lo menos nos lleva a una interfaz de usuario razonable, con una descripción del error sería preferible).

Answer 3

En sentido estricto, el segundo código tiene redundancia.

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

se ha producido aserción error medio. Algo que es inesperado / no controlada. En el código de seguridad, ya sea

1) Usted está manejando correctamente el caso en que p es nula. (Al no presentarse p> do ()) - que supuestamente es lo correcto / espera que lo haga. Sin embargo, a continuación, la afirmación es un falsa alarma .

2) Por otro lado, si al no presentarse p> do (), algo va a salir mal (tal vez más en el código o en la salida), entonces la afirmación es correcta, pero no debe haber ningún punto en continuar de todos modos.

En el código anterior el programador está trabajando muy duro para tramitar los asuntos que son de todos modos errónea.

Dicho esto, algunas personas como de tratar exponga como tiene algo malo ido, pero permite ver si todavía nos llegan salida correcta . OMI, que es una mala estrategia y crea confusiones durante la corrección de errores.

Answer 4

Las afirmaciones están depuración de código, que no opera al código. No los use a los errores de entrada de captura.

Answer 5

Las afirmaciones se utilizan para errores de captura en la prueba. La teoría es que se ha probado suficientemente bien como para saber que va a funcionar una vez que la soltó.

Si hay alguna posibilidad de que la condición podría surgir en el funcionamiento de la vida real, no se basan en afirmaciones -. Excepciones por el uso o algún otro mecanismo de error

Answer 6

Afirma son útiles para depurar como usted ha mencionado. Nunca deben hacerlo en el código de producción (como compilado, está bien para envolverlos en #ifdefs por supuesto)

Si se está ejecutando en un problema por el que está más allá de su control para rectificar y que necesita el cheque en su código de producción que haría algo como:

void f(int *p)
{

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

  p->do();
}

Donde do_error es una función que registra un error y sale limpiamente.

Answer 7

Yo digo dejarlos en en un comunicado de acumulación. No es probable que haya errores en cualquier formación. Tener afirma en sus medios de productos se puede identificar el problema con mayor facilidad cuando se recibe un informe de problema desde una Uwer.

no ponen mucho esfuerzo en el manejo de las excepciones. Simplemente asegúrese de que puede controlar la excepción completa, StackTrace includigg. Eso se aplica a una versión de lanzamiento en particular.

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 tiene decenas de horas a unos pocos días en completarse). Por lo tanto, tenemos macros especiales que afirman sólo en depurar código (ejecutar durante el control de calidad, etc.). A modo de ejemplo, una aserción dentro de un bucle for es definitivamente una sobrecarga y es posible que desee evitar que en el código de liberación. Después de todo, si todo iz así, asegura que no se supone que falla.

Un ejemplo en el código de liberación afirma son buenos es - si no se supone que la lógica para golpear una rama particular de código. En este caso, afirman (0) está bien [así cualquier tipo de aserción (0) siempre se puede dejar en código de liberación].