Siempre he seguido la lógica: si assert falla, entonces hay un error. causa raíz podría ser:Si falla la afirmación, ¿hay algún error?
POR EJEMPLO ¿Hay alguna otra conclusión a la que se pueda llegar? ¿Hay casos en que una afirmación fallaría y no hay errores?
Sí, hay un error en el código.
Las afirmaciones comprobar si hay condiciones que nunca debe ocurrir. [...]
Si una afirmación es despedido por un condición anómala, la acción correctiva es no sólo para manejar un error gracefully- la acción correctiva es cambiar el código fuente del programa, recompilación, y lanzar una nueva versión del software.
Una buena manera de pensar en afirmaciones es como ejecutable documentación - no se puede confiar en ellos para hacer que el código, pero que pueden supuestos documentos más activamente de comentarios en idioma programa puede.
Solo si la afirmación tenía la intención de mostrar una condición de advertencia, en cuyo caso se debería haber utilizado una clase especial de afirmación.
Por lo tanto, cualquier afirmación debe mostrar un error como usted sugiere.
El uso de aserciones como advertencias es un error e indica un malentendido de lo que significa la palabra "afirmar". –
Tenemos un código de depuración especial que arroja un mensaje similar a una afirmación, pero que permite que la ejecución continúe. Se llama assertWarn(). Más serio que un printf/log, pero no es digno de detenerse. Tengo curiosidad por lo que otros llamarían esto. –
Esa es una buena pregunta.
Mi sensación es que si la afirmación falla debido a su código, entonces es un error. La afirmación es un comportamiento/resultado esperado de su código, por lo que una falla de aserción será un error de su código.
Si la afirmación falla, hay un error en la persona que llama o en la persona que llama. ¿Por qué otra cosa habría una afirmación?
¿Por qué si no? No lo sé, es por eso que pregunté. Regularmente presento errores contra los desarrolladores para afirmar los pops que afirman son "por diseño". Solo quería asegurarme de que están equivocados/Estoy en la misma página que el mundo s/w :) – noctonura
Bueno, si se espera que falle, realmente no cumple con el requisito de una afirmación. Cuando dices: "Afirmo que esto es cierto", no estás diciendo que a veces o por lo general sea cierto, estás diciendo que es * siempre * verdadero. –
Fue una pregunta retórica. Una aseveración es una expectativa. 'assert (x == 5)' significa, "Creo que x será 5 aquí". Sin embargo, se usa de forma un tanto abusiva en el código de bajo nivel, por ejemplo, algunas personas dicen que solo debes usar la API de cierta manera o que el comportamiento no sea el adecuado y, a veces, se quedan en las afirmaciones para forzar la comprobación contra la entrada no válida. una advertencia o sale del programa. Esto está al borde de la estupidez, pero cualquier otra cosa que no sea esto derrota el propósito de una afirmación. –
Si está tratando de ser lógicamente incluyente sobre todas las posibilidades, recuerde que se sabe que los circuitos electrónicos se ven afectados por la radiación del espacio. Si el fotón/partícula correcto llega justo en el lugar correcto en el momento adecuado, puede provocar una transición de estado lógicamente imposible.
La probabilidad es infinitamente pequeña pero todavía no nula.
Si está utilizando afirmaciones, está siguiendo la filosofía Bertrand Meyer's Design by Contract. Es un error de programación: el cliente no confirma el contrato (afirmación) que ha especificado (llamador).
Por supuesto, el contrato puede no ser el correcto. Lo he hecho antes. Sin embargo, el contrato o el cliente tienen fallas. –
En realidad no. La afirmación es establecida por el contrato. Si el cliente no se conforma, ese es el problema. – andyczerwonka
que se puede pensar en un caso que realmente no clase como un error:
una aserción colocado para comprobar si hay algo externo que normalmente debería estar allí. Estás buscando algo loco que ocurre en una máquina y quieres saber si un determinado factor es responsable.
Un ejemplo del mundo real (aunque desde antes de la era de las afirmaciones): Si un determinado directorio estaba oculto en una máquina determinada, el programa sería ineficaz. Nunca encontré ningún fragmento de código que debería haberse importado si el directorio estaba oculto. Solo tenía acceso muy limitado a la máquina infractora (tenía un montón de cosas contables), así que no pude cazarla correctamente en la máquina y no pude reproducirla en ningún otro lado. Algo que se hizo con esa máquina (el culpable nunca se identificó) ocasionalmente convirtió ese directorio oculto.
Finalmente, recurrí a poner una prueba en el arranque para ver si el directorio estaba oculto y me detenía con un error si lo era.
No. Una falla de aserción significa que sucedió algo que el programador original no tenía la intención o la expectativa de que ocurriera.
Esto puede indicar:
Un error en el código (que son simplemente llamando al método incorrectamente)
Un error en la aserción (el programador original ha sido demasiado celosa protestó sobre usted haciendo algo que es bastante razonable y el método realmente se manejará perfectamente.
Un error en el código llamado (un error de diseño). Es decir, el código llamado proporciona un contrato que no todo debes hacer lo que tienes que hacer. La afirmación le advierte que no puede hacer las cosas de esa manera, pero la solución es extender el método llamado para manejar su entrada.
Característica conocida pero no implementada. Imagine que implemento un método que podría procesar enteros positivos y negativos, pero solo lo necesito (por ahora) para manejar los positivos. Sé que la implementación "perfecta" se encargaría de ambas cosas, pero hasta que yo realmente lo necesite para manejar los negativos, es un desperdicio de esfuerzo implementar soporte (y agregaría código hinchado y posiblemente ralentizaría mi aplicación). Así que he considerado el caso, pero decido no implementarlo hasta que se demuestre la necesidad. Por lo tanto, agrego una afirmación para marcar este código no implementado. Cuando más tarde desencadené la afirmación pasando un valor negativo, sé que ahora se necesita la funcionalidad adicional, por lo que debo aumentar la implementación. Aplazar la escritura del código hasta que realmente se requiera me ahorra mucho tiempo (en la mayoría de los casos, nunca realizo la función adicional), pero la afirmación asegura que no obtenga ningún error cuando intento usar la función no implementada.
Tiene 1,337 reputación. Eso es Leet. –
¡Ahora alguien lo arruinó! (Todavía tengo una captura de pantalla de cuando llegué a 1337 rep: p) – Thorarin
Una cosa que he visto mucho es afirmar que algún estado de entrada es "válido", p. el archivo que se está leyendo tiene el encabezado correcto. Sin embargo, esta es una afirmación "mala", como se espera si el archivo es falso, pero el archivo no está bajo control de programación. Es como afirmar que el usuario presiona la tecla Intro en lugar de la barra espaciadora. Informe el error, pero no use una afirmación. –