No detenga el depurador en esa excepción cuando se lanza y atrapa

En herramientas / excepciones, he establecido la opción de que el depurador se detenga cuando se lanza una excepción. Si está atrapado 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 progtwig. Entonces, obviamente, no quiero que esa excepción pare el depurador cada vez que se golpea.

Ejemplo: Deseo ignorar la excepción de nullreference (que está atrapada) en la línea 344. Quiero parar en todas las otras excepciones

Si recuerdo correctamente, puede usar un atributo DebuggerStepThrough 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 excepción molesta en un método y decorarlo con el atributo.

DebuggerHidden es tu amigo!

El tiempo de ejecución de lenguaje común no asigna semántica a este atributo. Se proporciona para el uso de 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 de depurador reconocidos por el depurador de Visual Studio 2005 son DebuggerNonUserCodeAttribute y DebuggerStepThroughAttribute.

Probado en VS2010 y funciona muy bien.

Aunque parece que DebuggerStepThrough también funciona para algunas versiones de depuración específicas, parece que DebuggerHidden funciona para una gama más amplia de situaciones en función de los comentarios de ambas respuestas.

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

DebuggerStepThrough es el que se utilizará para evitar que el depurador se rompa en un método donde hay un try / catch.

Pero solo funciona si no desmarcas 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, Depuración de nodos / 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 el depurador muestre el método donde se lanza la excepción. En cambio, mostrará el primer método en la stack que no está marcado con ese atributo …

Los atributos especificados en las otras respuestas (y otros como el atributo DebuggerNonUserCode ) ya no funcionan de la misma manera en Visual Studio 2015. El depurador se dividirá en excepciones en el mercado de métodos con esos atributos, a diferencia de versiones anteriores de VS. Para desactivar la mejora del rendimiento que modificó 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 

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

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

No puede seleccionar una excepción lanzada en un lugar específico en su código. Sin embargo, puede deshabilitar 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 cualquier ajuste, y luego inhabilitar la depuración en este tipo derivado.

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

Tenga en cuenta que hay 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 manejado por el usuario: si se selecciona, se rompe solo si la excepción, de este tipo, no es manejada por un try / catch.

Puede quitar el cheque en ‘Lanzado’ para la NullReferenceException que le dará la ventaja de no romper cada vez que su sistema pasa la línea en cuestión en su código, pero aún se rompe si tiene alguna expección NullReference no controlada que ocurra en otras partes del sistema.