Existe una discusión en comp.lang.c ++. Moderada sobre si las afirmaciones, que en C ++ solo existen en las compilaciones de depuración de forma predeterminada, deben mantenerse en el código de producción o no.
Obviamente, cada proyecto es único, por lo que mi pregunta aquí no es tanto si se deben mantener las afirmaciones, sino en qué casos es recomendable / no es una buena idea.
Por afirmación, quiero decir:
- Una verificación en tiempo de ejecución que prueba una condición que, cuando es falsa, revela un error en el software.
- Un mecanismo por el cual se detiene el programa (tal vez después de un trabajo de limpieza realmente mínimo).
No estoy necesariamente hablando de C o C ++.
Mi propia opinión es que si usted es el programador, pero no posee los datos (que es el caso con la mayoría de las aplicaciones comerciales de escritorio), debe mantenerlos encendidos, porque una aserción fallida muestra un error, y no debe ir con un error, con el riesgo de corromper los datos del usuario. Esto lo obliga a realizar una prueba exhaustiva antes de enviar, y hace que los errores sean más visibles, por lo que es más fácil de detectar y corregir.
¿Cuál es tu opinión / experiencia?
Salud,
Carl
Ver pregunta relacionada aquí
Respuestas y actualizaciones
Hola Graham
Una afirmación es error, pura y simple y, por lo tanto, debe manejarse como tal. Dado que un error debe manejarse en el modo de lanzamiento, realmente no necesita afirmaciones.
Es por eso que prefiero la palabra "error" cuando hablo de afirmaciones. Hace las cosas mucho más claras. Para mí, la palabra "error" es demasiado vaga. Un archivo que falta es un error, no un error, y el programa debería solucionarlo. Intentar desreferenciar un puntero nulo es un error, y el programa debe reconocer que algo huele a queso malo.
Por lo tanto, debe probar el puntero con una aserción, pero la presencia del archivo con el código normal de manejo de errores.
Ligeramente fuera de tema, pero un punto importante en la discusión.
Como aviso, si sus afirmaciones entran en el depurador cuando fallan, ¿por qué no? Pero hay muchas razones por las que un archivo podría no existir que están completamente fuera del control de su código: derechos de lectura / escritura, disco lleno, dispositivo USB desconectado, etc. Como no tiene control sobre él, creo que las afirmaciones son no es la forma correcta de lidiar con eso.
Carl
Thomas
Sí, tengo Code Complete, y debo decir que estoy totalmente en desacuerdo con ese consejo en particular.
Supongamos que su asignador de memoria personalizado se arruina y pone a cero un trozo de memoria que todavía utiliza algún otro objeto. Sucede que pongo a cero un puntero que este objeto desreferencia regularmente, y uno de los invariantes es que este puntero nunca es nulo, y tiene un par de afirmaciones para asegurarse de que se mantenga así. ¿Qué haces si el puntero de repente es nulo? ¿Solo si () a su alrededor, esperando que funcione?
Recuerde, aquí estamos hablando del código del producto, por lo que no hay que irrumpir en el depurador e inspeccionar el estado local. Este es un error real en la máquina del usuario.
Carl