Tener afirmaciones por condiciones inesperadas se considera una buena práctica de codificación defensiva. Yo coloco aserciones cada vez que pienso que algo inesperado puede suceder, pero ahora parece ser un exceso para mí.¿Dónde poner las afirmaciones?
Además, a veces las condiciones leves e inesperadas que no necesariamente provocan un bloqueo pueden incluso causar fallas en el cliente.
¿Existe una regla difícil y rápida para poner aserciones?
Gracias.
Las afirmaciones se formulan cuando usted está muy seguro de que algunas condiciones deben ser ciertas antes de pasar al siguiente nivel de su código. Por ejemplo, cuando un identificador de ventana no es válido o cuando algún varible no tiene un valor válido.
por lo que suena, los dejas activados en compilaciones de lanzamiento. de ser así, cree niveles de afirmaciones, aquellas que se habilitarán o deshabilitarán en ciertas compilaciones. entonces solo usa un nivel de afirmación.
de esta manera, no necesita rechazarlas, desactivarlas o eliminarlas para desarrollar y depurar construcciones o versiones beta.
normalmente los desactivo en lanzamiento, pero consumen una tonelada de código escrito. No creo que sea malo: sirve como documentación y exige que la interfaz se use como se pretendía. Creo que es bueno tener lo que muchos desarrolladores pueden considerar demasiadas afirmaciones, pero realmente no hay demasiadas en el panorama general porque las bases de código evolucionan y esto asegura que los programas se usen siempre como se esperaba. por lo tanto, no recomiendo eliminarlos, simplemente desactive los controles no fatales para compilaciones de versiones.
Finalmente, existen mejores enfoques que los niveles (consulte la discusión a continuación y tome lo que quiera de las respuestas de los demás), pero los niveles son una forma simple de introducir el cambio sin afectar considerablemente los programas existentes. este sería un buen enfoque para una transición a otro esquema de manejo de errores, o si estás> 98% satisfecho con lo que ya tienes.
No, no ... pero definitivamente recomendaría tratar las aserciones de manera diferente en pruebas y producción.
Está perfectamente bien, en un entorno de prueba, producir un volcado de memoria. Permite una fácil inspección de las condiciones que desencadenaron la afirmación de forma muy segura manteniendo todo el estado del programa.
Sin embargo, en un entorno de producción, nunca desea bloquearse (excepto en caso de daños en la memoria ...). El usuario espera que el sistema responda siempre, no hay nada más irritante que pedir algo y nunca recibir una respuesta. Por lo tanto, es su trabajo garantizar que el usuario obtenga la respuesta más significativa posible, incluso si se trata de un mensaje de error. La forma más simple de lograr esto es generalmente lanzar una excepción.
¿Dónde poner las afirmaciones?
Lo que a menudo se pasa por alto es que una afirmación también puede servir como ayuda para la documentación.
Así que no solo prueba lo "inesperado", también úsalas para expresar tus suposiciones (invariantes) en puntos críticos de tu código. Como assert(high >= low)
Y, por supuesto, hacerlos condicional, como otros han señalado aquí.
+1 para invariantes. – murrekatt
La principal diferencia entre el momento de usar afirmaciones y excepciones:
utilizar una afirmación para detectar errores de programación. Las afirmaciones nunca deberían suceder si el código se ha escrito correctamente.
Use excepciones para detectar los errores de tiempo de ejecución causados por un entorno inesperado.
Si su programa lee una secuencia de comandos o contenido de un archivo y no coinciden con el formato esperado, considero que es una condición de tiempo de ejecución, por lo tanto, una excepción.
Usted puede decidir, con fines de depuración, para usar una afirmación en el lugar donde se produce una excepción simplemente para poder trabajar con mayor facilidad en los que echaron, aunque se puede usar macros de excepción que insertan ARCHIVO y LINEA en el mensaje para hacer eso también.
+1 para una distinción clara entre aserciones y excepciones – davka
Solía pensar en los niveles de aserciones, pero es muy sorprendente cuando un error que fue atrapado en la prueba no se detecta en la producción. Además, he descubierto que los desarrolladores generalmente no sabían qué nivel aplicar, y más o menos elegían dependiendo de su estado de ánimo ... –
@Maththieu: es más limpio usar un manejador de condición fatal designado (y un mensaje de alerta o de registro) donde sea necesario y desactivar las aserciones para producción. por supuesto, esto depende de la relación de OP de las condiciones de error fatal y cómo se ha implementado el código existente. la excepción de mi código está libre cuando sea posible; los códigos/estados de error simplemente se envían a la persona que llama cuando se detectan o se encuentran. pero puede ser un gran desastre reescribir los programas existentes, por lo que sugerí niveles como una solución que no afectaría mucho al código existente. – justin