¿Debo usar la clase de depuración en .net?

StackOverflow https://stackoverflow.com/questions/1104748

  •  12-09-2019
  •  | 
  •  
¿Fue útil?

Solución

estoy muy de acuerdo con Ed Kaim. En lo personal, me siento como buenas prácticas de prueba han sustituido a las llamadas Debug.Assert en todo mi trabajo. Además, he abandonado más o menos mi uso de Debug.Fail así - cada vez que quiero usar esto, yo más o menos parece que quiero lanzar una excepción en la liberación, así como de depuración, por lo que no suelen ver el punto.

Una vez dicho esto, yo todavía uso de algunas de las declaraciones de impresión de depuración para aumentar mi depuración (a través de Debug.WriteLine), especialmente en código numérico ... Reconozco que es un retroceso a la depuración de printf de la vieja escuela, pero a menudo , que sigue siendo la forma más rápida de localizar a un problema, especialmente uno que no aparece en el depurador (debido a cuestiones de tiempo, roscado, etc.).

Otros consejos

En lo personal, que rara vez se utiliza la clase de depuración en absoluto para cualquiera de mi programación. He leído un montón de comentarios y sugerencias, tales como las de John Robbins (autor de la depuración de aplicaciones .NET 2.0 y las columnas Bugslayer ) acerca de por qué usted debe estar afirmando de forma proactiva -. especialmente para los parámetros de métodos

El problema que tengo es esta - dicen que era para escribir código como este: 

Public Sub Test(source As Object)

  Debug.Assert(source IsNot Nothing, "source is Nothing")

  ' Do something....
End Sub

Esto funciona bien durante el desarrollo con versiones de depuración, pero terminan haciendo esto de todos modos: 

Public Sub Test(source As Object)

  If source IsNot Nothing Then

  ' Do something....

  End If
End Sub

Si hay una posibilidad de 'fuente' a no ser nada, entonces me voy a hacer un 'Si' comprobar en él de todos modos. No voy a dejar la llamada aserción en la versión de lanzamiento.

La otra razón por la que no uso la clase de depuración es que escribo un montón de pruebas unitarias. Si lo hace, me ha llevado a cubrir una gran cantidad de rutas de código, teniendo así un Debug.Assert en mi código no es necesario.

En cuanto a registro de depuración, a continuación, simplemente uso rastrear las llamadas y SysInternals DebugView o archivos de texto para registrar la salida de las llamadas de seguimiento.

Me gustaría saber de otras personas sobre este tema, ya que yo también estoy interesado en saber cómo podrían estar utilizando la clase de depuración durante el desarrollo. Es un área que no tengo mucha experiencia en, así que estoy con ganas de aprender.

La principal ventaja de utilizar la clase de depuración sobre el código simplemente ejecutando en ti depurador es que se obtiene un archivo de registro (mediante declaraciones Debug.WriteLine), que se puede compartir con colegas / tienda para sus registros.

Las ventajas que Debug.Assert más ha escritura de un método de prueba separadas se compacidad, y el hecho de que el cheque es exactamente en el lugar que tiene que ser, en lugar de un método separado.

Mi propia opinión es que Debug.Assert y Debug.Fail a menudo se utilicen a los errores "ocultar" de los usuarios finales. Prefiero escribir en un registro de error o lanzar una excepción si se justifica.

No puedo decir si debería, pero lo que puedo sugerir veces cuando lo uso.

Yo uso de depuración cuando quiero más información acerca de una función / variables / proceso / resultado pero sé que una vez que se libera esa información ya no es relevante. Yo uso Debug.WriteLine para verificar la correcta cronología de un proceso, por ejemplo, o Debug.Assert para verificar un valor es lo que debería ser.

Creo Kaim es sólo decir que es fácil de hacer mal uso Debug.Assert. No utilice Debug.Assert para atrapar los problemas que podrían ocurrir en la producción. Debug.Assert es para verificaciones sencillas durante el desarrollo, como una bandera de aviso. No está destinado para manejar los errores de código de liberación. Usted puede poner un Debug.Assert cada dos líneas sin tener que preocuparse que está ralentizando el código de liberación.

Yo sugeriría a no utilizar la clase Debug en absoluto; Yo no. En general, encuentro para el desarrollo que el depurador es lo suficientemente bueno para todas mis necesidades; y lo que realmente necesita para realizar un seguimiento, me conecto. La parte más crítica acerca del registro es que el registro también se produce en el código de producción , que puede ser absolutamente importante. Debug por definición sólo es funcional en código de depuración; si bien puede ser útil para ayudar a encontrar algo durante el desarrollo, si es que importante encontrar, registrarlo. Seriamente. Si es importante para encontrar y suficiente que se necesita una instalación especial para llegar a ella complicado, registrarlo; es probable que aparezca en su entorno de producción como un caso extremo, y lo que va a hacer entonces?

Y por si sirve de algo, creo que log4net a ser increíblemente útil y robusto para fines de registro. Me gustaría recomendar su uso sobre el uso de la clase Debug cualquier día.

Utilizamos Debug.Assert muy a menudo - para cada supuesto importante que usted haría no perjudicar a tener una aserción

.

Todo un útil pero viejo artículo - IDesign C # Estándares de Codificación aquí

prueba Debug.Assert de contrato. Tiene un poco beneficio que no está presente en el código de liberación. Ese no es el caso si dura más de tirar caso es una excepción.

Yo uso Debug.WriteLine para los eventos de interfaz de usuario porque hay depurador interpone en el camino (por ejemplo refrescar eventos son llamados de nuevo al cambiar de ventana a ventana de la aplicación VS).

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top