try - tipos de excepciones en c#
La interrupción de Visual Studio 2015 en excepciones no controladas no funciona (12)
Cuando actualicé a VS2015, también tuve problemas en los que las excepciones solían "romper" la aplicación, pero ahora se ignoran y se pasan por alto.
Hay momentos en que queremos que nuestro código arroje 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 produce cuando decimos
Throw New Exception
.
Por lo tanto, necesitábamos marcar la marca "System.Exception" en la nueva Configuración de excepción:
Marque la casilla de System.Exception
Una vez verificado, nuestro código hizo lo esperado.
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 mudó a algún lugar donde no puedo encontrarlo). Así que ahora mis proyectos convertidos ya no se rompen si no puedo proporcionar un controlador de excepciones a nivel de usuario. No quiero romper todas las "excepciones lanzadas" porque manejo las 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? Acabo de actualizar a la edición de la comunidad ayer.
Definitivamente hay algún error en Visual Studio que puede hacer que se atasque y requiera un reinicio. Incluso VS2015.
Tuve una situación de subproceso único en la que un controlador ''externo'' (todavía en mi código) atrapaba una
NullReferenceException
a pesar de que pedí que se rompiera cuando se levantó.
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.
En mi experiencia, la configuración de excepciones en 2015 se pierde completamente si cambias algo.
Espere que si hasta el grupo padre "CLR" no debería obtener ningún exento de ruptura por no manejado. Siempre se romperá si una excepción no se maneja. Pero, si tiene el grupo CLR sin marcar, codifique dentro de un intento ... captura 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 elija "restaurar predeterminado". Taadaaaa ... Se comporta normalmente de nuevo. Ahora no lo jodas.
Hay una nueva ventana llamada "Configuración de excepción" que aparece en el panel inferior derecho de forma predeterminada cuando comienza a depurar. Tiene todas las opciones que esperarías.
Puedes mencionarlo con CTRL + ALT + E
Esto le permite elegir 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 es 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 (Romper al lanzar) en la nueva ventana de Configuración de excepciones y agregar la columna "Acciones adicionales", que luego le permite configurar cada excepción como "Continuar cuando no se maneja en el código de usuario".
Por lo tanto, simplemente haga clic con el botón derecho en una excepción o en un grupo completo y desactive la marca "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 el código de usuario".
Más sobre esto aquí:
Intenta seguir las instrucciones:
- En la ventana Configuración de excepción, abra el menú contextual haciendo clic derecho en la ventana y luego seleccionando Mostrar columnas. (Si ha desactivado Just My Code, no verá este comando).
- Debería ver una segunda columna llamada Acciones adicionales. Esta columna muestra Continuar cuando el código de usuario no lo maneja en excepciones específicas, lo que significa que el depurador no se rompe si esa excepción no se maneja en el código de usuario sino que se maneja en código externo.
- Puede cambiar esta configuración para una excepción particular (seleccione la excepción, haga clic con el botón derecho y seleccione / deseleccionar 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).
La solución es que esto es semánticamente lo opuesto a lo que crees que estás configurando. Debe asegurarse de que Continuar cuando no se maneja 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 excepción : consulte a continuación:
efectivamente está diciendo que no continúe (es decir, se rompa) cuando no se maneja en el código
Para hacer esto:
- Haga clic con el botón derecho en la excepción o conjunto de excepciones que le interesan (es decir, generalmente la línea superior ''Excepciones de Common Language Runtime'' en el árbol)
- Seleccione la opción Continuar cuando no se maneja en el código de usuario (ver más abajo)
- Asegúrese de que las excepciones no estén marcadas (ver más abajo)
- continuar depurando
Eso lo hizo por mí, feliz de nuevo.
Esto fue en VS 2015
Microsoft ha cambiado sutilmente la lógica en la nueva ventana de excepciones.
La parte clave es:
Notas importantes
- Esta nueva ventana contiene todas las mismas funciones que el antiguo diálogo modal. Ninguna capacidad del depurador ha cambiado solo la forma en que puede acceder a ellos
- El depurador siempre se interrumpirá cuando no se maneje una excepción
- La configuración para cambiar si el depurador se rompe en excepciones no controladas por el usuario se ha movido bajo 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 excepción global no controlada en su código, el segundo elemento de esa lista es clave: para mí, por lo tanto, no habrá excepciones, lo que parece ser diferente de VS2013.
Para recuperar el comportamiento en el que VS se rompe en excepciones no controladas, tuve que marcar todos los tipos de excepción que quería romper y luego 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 excepción global no controlada se "maneje en el código de usuario", por lo que se rompe en estos; sin embargo, no se rompe con las excepciones detectadas. Esto hace que funcione como lo hizo VS2013.
Para los buscadores de Google que quieran interrumpirse solo cuando la excepción se refiera a su código, hay una opción en Visual Studio 2015: Opciones-> Depuración-> General-> Solo mi código. Una vez marcado, permite que no se rompa cuando la excepción se gestiona (arroja y atrapa) fuera de su código.
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 romperse en las excepciones no controladas.
Si tiene métodos asincrónicos, es posible que se encuentre con este problema porque las excepciones no capturadas en un subproceso de grupo de subprocesos como parte de una continuación de la Tarea no se consideran excepciones no controladas. Más bien, son tragados y almacenados 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ándolo a la instancia de la tarea) y se libera de nuevo al grupo.
Tenga en cuenta que, en este caso, el problema real es que la
Task
devuelta por
Test()
nunca se verifica.
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.
Todo es un poco confuso, y en mi opinión no es tan bueno como el antiguo cuadro de diálogo de excepciones, pero de todos modos.
Si hay una excepción en la lista y está marcada, el depurador se interrumpirá cada vez que se lance la excepción.
Si una excepción no está marcada o no está en la lista, entonces el depurador solo se interrumpirá cuando ese tipo de excepción no sea manejado por el usuario.
Por ejemplo, en la captura de pantalla a continuación, el depurador se interrumpirá cada vez que se lanza una excepción
System.AccessViolationException
, pero para todas las demás excepciones, solo se interrumpirá si la excepción no fue manejada por el usuario.
Tuve el mismo problema y logré resolver esto haciendo esto:
- Presione Ctrl + Alt + e para abrir la ventana Configuración de excepción .
- Marque Excepciones de Common Language Runtime .
¡Eso es!
Me inspiró esta post ya que estoy usando una versión x64 de Windows .
Visual Studio 2017 funciona bien con el manejo de errores. Visual Studio 2015, por otro lado, apesta al manejo de errores con las tareas porque en el modo de depuración se detectan todas las excepciones que ocurren en una tarea asincrónica, pero luego, si paso por encima, simplemente se cuelga indefinidamente. Si se ejecuta sin depurar, se cuelga indefinidamente sin que se detecte ninguna excepción. Me encanta el estudio visual 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 hacer 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 porque Microsoft introdujo tareas en un marco que el compilador de 2015 no puede manejar correctamente.