La interrupción de Visual Studio 2015 en excepciones no controladas no funciona

Visual Studio solía tener una casilla de verificación específica para "Romper en excepción no controlada". En 2015 esto se eliminó (o se movió a algún lugar donde no puedo encontrarlo). Así que ahora mis proyectos convertidos ya no se rompen si no proporciono un controlador de excepciones a nivel de usuario. No quiero interrumpir todas las "excepciones lanzadas" porque manejo algunas específicas. Justo donde no puedo proporcionar un controlador específico.

En este momento, mi código simplemente sale del procedimiento actual y continúa la ejecución en la siguiente ubicación de la pila de llamadas, NO ES BUENO.

¿Alguien sabe cómo recuperar esto en Visual Studio 2015? Ayer me actualicé a la edición comunitaria.

Hay una nueva ventana llamada "Configuración de excepciones" que aparece en el panel inferior derecho de forma predeterminada cuando comienza a depurar. Tiene todas las opciones que cabría esperar.

Puedes mencionarlo con CTRL+ ALT+E

Esto le permite seleccionar qué excepciones causan una interrupción en el depurador.

Sin embargo, la clave es que también puede establecer si estas excepciones siempre se rompen o solo se rompen cuando se trata de una excepción no controlada, pero configurar esto no es muy intuitivo.

Primero deberá marcar "Habilitar solo mi código" en Herramientas> Opciones> Depuración.

Esto le permite hacer clic con el botón derecho en el encabezado de la columna (Interrumpir cuando se lanza) en la nueva ventana Configuración de excepciones y agregar la columna "Acciones adicionales", que luego le permite establecer cada excepción como "Continuar cuando no se maneja en el código de usuario".

Así que simplemente haga clic con el botón derecho en una excepción o en un grupo completo y desactive la bandera "Continuar cuando no se maneja en el código de usuario". Desafortunadamente, la columna "Acciones adicionales" aparecerá vacía, lo que es lo mismo que "Romper cuando no se maneja en el código de usuario".

Más sobre esto aquí:

http://blogs.msdn.com/b/visualstudioalm/archive/2015/02/23/the-new-exception-settings-window-in-visual-studio-2015.aspx

Tuve el mismo problema y logré resolver esto haciendo esto:

1. Presione Ctrl+ Alt+ epara abrir la ventana Configuración de excepciones .
2. Marque Excepciones en tiempo de ejecución de lenguaje común .

¡Eso es!

Me inspiré en esta publicación porque estoy usando una versión x64 de Windows .

Para los usuarios de Google que quieran romper solo cuando la excepción se refiere a su código, hay una opción en Visual Studio 2015: Opciones-> Depuración-> General-> Solo mi código. Una vez marcada, permite que no se rompa cuando la excepción se gestiona (se lanza y se captura) fuera de su código.

Microsoft ha cambiado sutilmente la lógica en la nueva ventana de excepciones.

Ver http://blogs.msdn.com/b/visualstudioalm/archive/2015/02/23/the-new-exception-settings-window-in-visual-studio-2015.aspx

La parte clave es:

Notas importantes

• Esta nueva ventana contiene todas las mismas funciones que el cuadro de diálogo modal anterior. Ninguna capacidad del depurador ha cambiado solo la forma en que puede acceder a ellas
• El depurador siempre se interrumpirá cuando no se controle una excepción
• La configuración para cambiar si el depurador se interrumpe en las excepciones no controladas por el usuario se ha movido a un menú contextual
• La ubicación del menú se ha movido a Depurar -> Windows -> Configuración de excepción

Sin embargo , si, como yo, tiene un controlador de excepciones global no manejado en su código, entonces el segundo elemento de esa lista es clave: para mí, no habrá excepciones, por lo tanto, que parecen ser diferentes de VS2013.

Para recuperar el comportamiento en el que VS se interrumpe en las excepciones no controladas, tuve que marcar todos los tipos de excepciones en los que quería interrumpir y luego, en segundo lugar, asegurarme de que las "Opciones adicionales" (es posible que deba hacer que esta columna sea visible *) para "Continuar cuando no se maneja en el código de usuario " NO se configuró. La lógica VS2015 no parece considerar que mi Controlador de excepciones no manejadas global se "maneje en el código de usuario", por lo que se rompe en estos; Sin embargo, no se rompe en excepciones detectadas. Esto hace que funcione como lo hizo VS2013.

* Cómo habilitar la columna "Acciones adicionales"

Si estoy leyendo correctamente entre líneas aquí, el problema es que su excepción está efectivamente 'desapareciendo' a pesar de que el comportamiento del depurador predeterminado debería interrumpirse en las excepciones no controladas.

Si tiene métodos asincrónicos, es posible que tenga este problema porque las excepciones que no se detectan en un subproceso del grupo de subprocesos como parte de una continuación de la tarea no se consideran excepciones no controladas. Más bien, se ingieren y almacenan con la tarea.

Por ejemplo, eche un vistazo a este código:

class Program
{
    static void Main(string[] args)
    {
        Test();
        Console.ReadLine();
    }

    private async static Task Test()
    {
        await Task.Delay(100);
        throw new Exception("Exception!");
    }
}

Si ejecuta este programa con la configuración predeterminada del depurador (se detiene solo en excepciones no controladas), el depurador no se interrumpirá. Esto se debe a que el subproceso del grupo de subprocesos asignado a la continuación se traga la excepción (pasándola a la instancia de Task) y se libera de nuevo al grupo.

Tenga en cuenta que, en este caso, el problema real es que el Taskdevuelto por Test()nunca se comprueba. Si tiene tipos similares de lógica de 'disparar y olvidar' en su código, entonces no verá las excepciones en el momento en que se lanzan (incluso si están 'no controladas' dentro del método); la excepción solo aparece cuando observa la Tarea esperándola, verificando su Resultado o mirando explícitamente su Excepción.

Esto es solo una suposición, pero creo que es probable que estés observando algo como esto.

En mi experiencia, la configuración de excepción en 2015 se desequilibra por completo si cambia algo.

Espere que si llega al grupo principal "CLR", no debería obtener ningún execpt de ruptura por no controlado. Siempre fallará si una excepción no se maneja. Pero, si tiene el grupo CLR sin marcar, el código dentro de un try ... catch simplemente no debería causar una interrupción. Ese no es el caso.

Solución: en la nueva caja de herramientas de configuración de excepciones, haga clic con el botón derecho y seleccione "restaurar predeterminado". Taadaaaa ... Se comporta normalmente de nuevo. Ahora no lo jodas.

Intente seguir las instrucciones:

1. En la ventana Configuración de excepción, abra el menú contextual haciendo clic con el botón derecho en la ventana y luego seleccionando Mostrar columnas. (Si ha desactivado Just My Code, no verá este comando).
2. Debería ver una segunda columna denominada Acciones adicionales. Esta columna muestra Continuar cuando no lo controla el código de usuario en excepciones específicas, lo que significa que el depurador no se interrumpe si esa excepción no se maneja en el código de usuario, sino en un código externo.
3. Puede cambiar esta configuración para una excepción en particular (seleccione la excepción, haga clic con el botón derecho y seleccione / anule la selección de Continuar cuando no se maneje en el código de usuario) o para una categoría completa de excepciones (por ejemplo, todas las excepciones de Common Language Runtime).

https://msdn.microsoft.com/en-us/library/x85tt0dd.aspx

Todo es un poco confuso y, en mi opinión, no es tan bueno como el antiguo diálogo de excepciones, pero de todos modos.

Si hay una excepción en la lista y está marcada, el depurador se interrumpirá siempre que se lance la excepción.

Si una excepción no está marcada o no está en la lista, el depurador solo se interrumpirá cuando el usuario no controle ese tipo de excepción.

Por ejemplo, en la captura de pantalla a continuación, el depurador se interrumpirá cada vez que System.AccessViolationExceptionse lance un, pero para todas las demás excepciones, solo se interrumpirá si el usuario no manejó la excepción.

Cuando actualicé a VS2015, también tuve problemas en los que las excepciones solían "interrumpir" la aplicación, pero ahora se ignoran y se pasan por alto. Hay ocasiones en las que queremos que nuestro código genere excepciones intencionalmente en lugares donde queremos que el código se detenga, en lugar de continuar. Siempre usamos la frase Throw New Exception("Message")para que nuestro código se rompa intencionalmente:

    If SomethingReallyBad = True Then
        Throw New Exception("Something Really Bad happened and we cannot continue.")
    End If

Con VS2015, el clásico "System.Exception" es lo que se lanza cuando decimos Throw New Exception. Por lo tanto, necesitábamos marcar la marca "System.Exception" en la nueva configuración de excepciones:

Marque la casilla System.Exception

Una vez verificado, nuestro código funcionó como se esperaba.

La solución es semánticamente opuesta a lo que crees que estás configurando. Debe asegurarse de que Continuar cuando no se maneja en el código de usuario no esté habilitado, es decir, no esté marcado como se muestra en la columna Acciones adicionales en la pestaña Configuración de excepciones ; consulte a continuación:

efectivamente está diciendo no continuar (es decir, romper) cuando no se maneja en el código

Para hacer esto:

1. Haga clic con el botón derecho en la excepción o el conjunto de excepciones que le interesan (es decir, generalmente en la línea superior 'Excepciones de tiempo de ejecución de lenguaje común' en el árbol)
2. Seleccione la opción Continuar cuando no se maneja en el código de usuario (ver más abajo)
3. Asegúrese de que las excepciones no estén marcadas (ver más abajo)
4. continuar depurando

Eso fue todo por mí, feliz de nuevo.

Esto fue en VS 2015

Definitivamente hay algún error en Visual Studio que puede hacer que se atasque y sea necesario reiniciar. Incluso VS2015.

Tuve una situación de un solo hilo en la que un NullReferenceExceptioncontrolador 'externo' (todavía en mi código) atrapaba a a pesar de que pedí que se rompiera cuando se generó.

Me doy cuenta de que esta es una excepción 'manejada' y estás hablando de una 'no manejada'; sin embargo, estoy bastante seguro de que a veces un reinicio rápido de VS solucionará esto, si IISRESET no lo hace.

Visual Studio 2017 funciona bien con el manejo de errores. Visual Studio 2015, por otro lado, apesta en el manejo de errores con tareas porque en el modo de depuración se detectan todas las excepciones que ocurren en una tarea asíncrona, pero luego, si paso por encima, simplemente se cuelga indefinidamente. Si se ejecuta sin depurar, se cuelga indefinidamente sin excepción. Me encanta Visual Studio y lo he estado usando desde 1995 y 2015 es la peor versión, aunque salté de 2010 directamente a 2015. Pasé 8 horas tratando de que este manejo de excepciones funcionara sin éxito. Copié el código exacto a 2017 en la computadora de mi casa y funcionó perfectamente. Estoy muy irritado de que Microsoft haya introducido tareas en un marco que el compilador de 2015 no puede manejar correctamente.