No detenga el depurador en ESA excepción cuando se lanza y se detecta

91

En herramientas / excepciones, configuré la opción de que el depurador se detenga cuando se lanza una excepción. Ya sea que lo atrapen o no.

¿Cómo excluyo una excepción de esa regla? En algún lugar de mi código hay una excepción detectada que es parte de la lógica del programa. Entonces, obviamente, no quiero que esa excepción detenga el depurador cada vez que se golpea.

Ejemplo: quiero ignorar la excepción de referencia nula (que se detecta) en la línea 344. Quiero detenerme en todas las demás excepciones.

— MichaelD
fuente

6

Cuando esta excepción es parte de su lógica de programación (piense, si realmente tiene que implementarla de esta manera), entonces debería ser al menos una excepción derivada creada por usted mismo. De esta forma puedes aplicar la solución de Brian.

— tanascius

Aquí está el problema: stackoverflow.com/questions/1957907/…

— MichaelD

2

@tanascius - +1 Estoy de acuerdo en la mayoría de los casos Las excepciones no son la mejor manera de tomar una decisión lógica; sin embargo, en algunos casos, como cuando la deserialización de excepciones de manejo es a veces inevitable, throw> catch> handle es la única opción razonable.

— jpierson

2

@Ando lo siento mi mal. La moderación de varias pestañas a la vez es eficaz, pero no siempre precisa.

2

@tanascius: es posible que aún tenga que detectar una excepción de marco conocida antes de poder lanzar la suya propia en respuesta. Tu sugerencia no siempre es posible.

— Dan Puzey

40

Si mal no recuerdo, puede usar un DebuggerStepThroughatributo en el método que contiene el código que no desea que se active la excepción. Supongo que puedes aislar el código que dispara la molesta excepción en un método y decorarlo con el atributo.

— Chris Chou
fuente

31

De la respuesta de simulador y mi experiencia, esta respuesta parece ser incorrecta. El DebuggerStepThroughatributo no afecta el comportamiento del depurador con excepciones de primera oportunidad.

— Michael Petrotta

5

@Tim, lo probé y NO se detiene. revisa mi respuesta: stackoverflow.com/questions/1420390/3455100#3455100

— Shimmy Weitzhandler

1

+1 funciona en VS2010 para código puro .NET 4.0 y Silverlight 4 para excepciones no controladas.

— Mike Post

6

Nota importante: esto no funciona para los métodos de tipo async-await. Más aquí

— i3arnon

8

Según MSDN, el DebuggerStepThroughatributo no tiene ningún significado para CLR. Es interpretado por depuradores. Parece que no funciona de manera confiable en una variedad de circunstancias, y eso DebuggerHiddenfuncionará de manera confiable stackoverflow.com/a/3455100/141172

— Eric J.

64

DebuggerHidden ¡es tu amigo!

Common Language Runtime no adjunta semántica a este atributo. Se proporciona para que lo utilicen los depuradores de código fuente. Por ejemplo, el depurador de Visual Studio 2005 no se detiene en un método marcado con este atributo y no permite establecer un punto de interrupción en el método. Otros atributos del depurador reconocidos por el depurador de Visual Studio 2005 son DebuggerNonUserCodeAttribute y DebuggerStepThroughAttribute.

Probado en VS2010 y funciona muy bien.

Si bien DebuggerStepThroughparece funcionar también para algunas versiones específicas del depurador, DebuggerHiddenparece funcionar para una gama más amplia de situaciones según los comentarios de ambas respuestas.

Tenga en cuenta que ambas opciones no funcionan actualmente con métodos de bloque de iterador o con métodos asíncronos / en espera . Esto podría solucionarse en una actualización posterior de Visual Studio.

— Shimmy Weitzhandler
fuente

trabajando en VS2008. Debe aplicarlo a todo el método, incluido el bloque de captura, o simplemente se romperá en otro lugar

— Mark Heath

1

Agregué ese atributo a un método y el depurador simplemente se detuvo en el método de llamada. ¿Me estoy perdiendo de algo?

— Doogal

1

Así es como debería ser. para evitar eso, tendrá que manejar la excepción ... O, alternativamente, marcar también el método de la persona que llama DebuggerHidden...

— Shimmy Weitzhandler

1

Tenga en cuenta que el atributo DebuggerStepThrough debería ser suficiente para evitar fallas en las excepciones. DebuggerHidden actúa como una combinación de DebuggerNonUserCode y el atributo DebuggerStepThrough.

— jpierson

1

Lamentablemente, esto no funciona si el método en cuestión es un método iterador : /

— Roman Starkov

14

DebuggerStepThrough es el que se utilizará para evitar que el depurador interrumpa un método en el que hay un intento / captura.

Pero solo funciona si no desmarcó la opción "Habilitar solo mi código (solo administrado)" en la configuración general de las opciones de depuración de Visual Studio (menú Herramientas / Opciones, nodo Depuración / General) ...

Más información sobre ese atributo en http://abhijitjana.net/2010/09/22/tips-on-debugging-using-debuggerstepthrough-attribute/

DebuggerHidden simplemente evitará que Debugger muestre el método donde se lanza la excepción. En su lugar, mostrará el primer método de la pila que no está marcado con ese atributo ...

— Valery Letroye
fuente

1

Tenga en cuenta que esto ya no funciona de forma predeterminada en VS 2015, consulte el blog de VS para saber cómo habilitarlo

— bhh

Lamentablemente, la

— Jonathan Allen

13

Los atributos especificados en las otras respuestas (y otros como el DebuggerNonUserCodeatributo) ya no funcionan de la misma manera de forma predeterminada en Visual Studio 2015. El depurador se interrumpirá en las excepciones en el mercado de métodos con esos atributos, a diferencia de las versiones anteriores de VS. Para desactivar la mejora de rendimiento que cambió su comportamiento, debe cambiar una configuración de registro:

reg add HKCU\Software\Microsoft\VisualStudio\14.0_Config\Debugger\Engine /v AlwaysEnableExceptionCallbacksOutsideMyCode /t REG_DWORD /d 1

Puede encontrar más información en el blog de Visual Studio .

(Esto probablemente debería ser un comentario sobre la respuesta principal, pero no tengo suficiente representante)

— bhh
fuente

3

No puede identificar una excepción lanzada en un lugar específico de su código. Sin embargo, puede desactivar excepciones de un tipo específico.

Si su propio código arroja la excepción en cuestión, la convertiría en una excepción personalizada, derivada de lo que se ajuste, y luego deshabilitaría la ruptura de depuración en este tipo derivado.

La desactivación de excepciones del sistema como NullReferenceException afectará a todo el sistema, lo que, por supuesto, no es deseable durante el desarrollo.

Tenga en cuenta que existen dos tipos de comportamientos de ruptura para las excepciones:

Lanzado: si se selecciona, se rompe tan pronto como se lanza una excepción de este tipo
No gestionado por el usuario: si se selecciona, se interrumpe solo si la excepción de este tipo no se gestiona mediante un intento / captura.

Puede eliminar el check en 'Thrown' para NullReferenceException, lo que le dará el beneficio de no romperse cada vez que su sistema pasa la línea en cuestión en su código, pero aún se rompe si tiene alguna expectativa de NullReference no controlada que ocurre en otras partes de la sistema.

— Lars Udengaard
fuente

3

Agregar el atributo DebuggerStepThrough a un método en Visual Studio 2010 evitará que el depurador detenga una excepción no controlada lanzada por el método.

— Tim Murphy

Probé y no previene; todavía se detiene

— Shimmy Weitzhandler

1

@Shimmy - ¡Funciona para mí! Asegúrese de aplicar DebuggerStepThrough a cada método desde el punto en el que se lanza hasta el punto en el que desea que la excepción sea visible dentro de la pila de llamadas. Si detecta la excepción y la maneja dentro de la jerarquía de llamadas donde todos los métodos están decorados con DebuggerStepThrough, nunca debería ver a VS romper en esa excepción.

— jpierson