open ejemplos debug c# .net debugging assertions

debug - assert c# ejemplos



¿Debería Debug.Assert y Debug.Fail ser usado generosamente, y deberían dejarse en código de producción? (5)

Estoy leyendo un libro que afirma (juego de palabras) "Debe cargar su código con los métodos Debug.Assert cuando tenga una condición que siempre será verdadera o falsa".

No he estado usando estos dos métodos de depuración, pero tiene sentido. Sin embargo, odio que estas cosas se desparramen por todas mis bases de código de producción.

¿Pensamientos?


Depende de para qué lo estés usando. Si lo usa para hacer afirmaciones dentro de sus propios métodos, para garantizar que funcionen correctamente, creo que está bien , pero preferiría las pruebas unitarias para validar todo lo que pueda pensar si es posible.

No es una buena idea (IMO) usarlo para validar la entrada entrante, por ejemplo, los parámetros. En ese caso, creo que es mucho más consistente usar excepciones en la forma normal de:

if (foo == null) { throw new ArgumentNullException("foo"); }

En mi opinión, este comportamiento no debería cambiar solo porque está ejecutando el código de versión.


Está bien, ya que el compilador lo omite en la versión de lanzamiento. No es una mala práctica, y no es necesario que los elimines de la fuente (de hecho, probablemente no deberías). Pero debes tener cuidado:

Debug.Assert(SomethingImportantThatMustExecute());

es malo : el SomethingImportantThatMustExecute se ignorará en la versión; debes usar:

bool result = SomethingImportantThatMustExecute() Debug.Assert(result);

Básicamente, evite los efectos secundarios en las llamadas a métodos condicionales y métodos parciales.


Puede utilizar Debug.Assert generosamente en bases de código de producción. Debug.Assert está decorado con ConditionalAttribute . Si compila su código en la configuración "realease", el compilador omitirá las llamadas a Debug.Assert .


Sí, las afirmaciones están bien. Y tenga en cuenta que no solo son controles lógicos (eso es obvio) sino que también sirven como una forma de documentación, más confiable que los comentarios.

Pero piense de antemano en la prueba de unidad. Si va a probar la compilación de depuración, los resultados (con respecto a la lógica de error) pueden ser diferentes de su versión de lanzamiento.

Para las comprobaciones de que desea estar activo en la versión de lanzamiento, puede utilizar Trace.Assert ().

Y nadie mencionó los contratos de código todavía, una forma más rica y estructurada de verificar y documentar su código.


Si compila una versión de compilación (utilizando la configuración del proyecto de Visual Studio), todas las declaraciones Debug.Assert se eliminarán automáticamente. Así que sí, úsalos generosamente.