Por qué is.NET excepción no atrapada por el bloque try/catch?

Independientemente de si el ensamblado ha sido compilado como una compilación de liberación, la excepción ciertamente debería 'burbujear' hasta el autor de la llamada, no hay ninguna razón por la que un ensamblado que no esté compilado en modo de depuración deba tener algún efecto en eso.

Estoy de acuerdo con Daniel está sugiriendo que tal vez la excepción está ocurriendo en un subproceso separado - intente conectar el evento de excepción de subproceso en la Aplicación.ThreadException. Esto debe ser elevado cuando se produce cualquier excepción de hilo no manejado. Podrías adaptarte su código así: -

using System.Threading;

...

void Application_ThreadException(object sender, ThreadExceptionEventArgs e) {
  throw new ParserException(e.Exception.Message, e.Exception);
}    

 ...

 var exceptionHandler = 
    new ThreadExceptionEventHandler(Application_ThreadException);
 Application.ThreadException += exceptionHandler;
 try {
    // Execution stopped at parser.prog()
    TimeDefParser.prog_return prog_ret = parser.prog();
    return prog_ret == null ? null : prog_ret.value;
 }
 catch (Exception ex) {
    throw new ParserException(ex.Message, ex);
 }
 finally {
    Application.ThreadException -= exceptionHandler;
 }

Puedo decirles lo que está pasando aquí...

Visual Studio se está rompiendo porque cree que la excepción no está controlada. ¿Qué significa no manejado? Bueno, en Visual Studio, hay una configuración en las Herramientas... Opcion... Depuración... General... "Enable Just My Code (Managed only)" (en inglés). Si esto está marcado y si la excepción se propaga fuera de su código y hacia un marco de pila asociado con una llamada a un método que existe en un ensamblado que NO es "SU CÓDIGO" (por ejemplo, Antlr), es considerado "sin control". Apago que Habilitar Solo Mi Función de Código por esta razón. Pero, si me preguntas, esto es patético... digamos que haces esto:

ExternalClassNotMyCode c = new ExternalClassNotMyCode();
try {
    c.doSomething( () => { throw new Exception(); } );
}
catch ( Exception ex ) {}

DoSomething llama a su función anónima allí y esa función lanza una excepción...

Tenga en cuenta que esta es una "excepción no controlada" de acuerdo con Visual Studio si "Habilitar solo mi código" está activado. Además, tenga en cuenta que se detiene como si fuera un punto de interrupción cuando está en modo de depuración, pero en un entorno sin depuración o producción, el código es perfectamente válido y funciona como se esperaba. Además, si solo "continúas" en el depurador, la aplicación continúa de manera feliz (no detiene el hilo). Se considera "unhandled" porque la excepción se propaga a través de un marco de pila que NO está en su código (es decir, en la biblioteca externa). Si me preguntas, esto es pésimo. Por favor, cambie este comportamiento predeterminado Microsoft. Este es un caso perfectamente válido de usar Excepciones para controlar la lógica del programa. A veces, no se puede cambiar el tercero biblioteca para comportarse de cualquier otra manera, y esta es una forma muy útil para llevar a cabo muchas tareas.

Tome MyBatis por ejemplo, puede usar esta técnica para detener el procesamiento de registros que están siendo recopilados por una llamada a SqlMapper.Consulta con la delegación.

¿Está utilizando. Net 1.0 o 1.1? Si es así, catch (Exception ex) no capturará excepciones de código no administrado. Necesitarás usar catch {} en su lugar. Vea este artículo para más detalles:

Http://www.netfxharmonics.com/2005/10/net-20-trycatch-and-trycatchexception /

¿Es posible que la excepción esté siendo lanzada en otro hilo? Obviamente, su código de llamada es un subproceso simple, pero tal vez la biblioteca que está consumiendo está haciendo algunas operaciones multiproceso bajo las portadas.

Estoy con @ Shaun Austin - trate de envolver el intento con el nombre completo

catch (System.Exception)

Y ver si eso ayuda.¿El médico de ANTLR dice qué excepciones deben ser lanzadas?

Personalmente no estoy convencido por la teoría del hilo en absoluto.

La única vez que he visto esto antes, estaba trabajando con una biblioteca que también definía Excepción y los usos que había significado que la Captura real se refería a un tipo de "Excepción" diferente (si había sido totalmente calificado era Empresa.Lib.Excepción, pero no fue debido al uso) así que cuando se trataba de atrapar una excepción normal que se estaba lanzando (algún tipo de excepción de argumento si recuerdo correctamente) simplemente no captura porque el tipo no coincide.

Así que en resumen, ¿hay otro tipo de excepción en un espacio de nombres diferente que esté en un using en esa clase?

EDITAR: Una forma rápida de comprobar esto es asegurarse de que en su cláusula catch califica completamente el tipo de excepción como "System.Excepción " y darle un giro!

EDIT2: OK He probado el código y reconozco la derrota por ahora. Tendré que echarle otro vistazo por la mañana si a nadie se le ha ocurrido una solución.

Para mí, una cláusula catch (Excepción) debería haber capturado cualquier excepción. ¿Hay alguna razón por la que no lo haría?

La única posibilidad en la que puedo pensar es que algo más lo está atrapando ante usted y manejándolo de una manera que parece ser una excepción no capturada (por ejemplo, salir del proceso).

Mi bloque try/catch no lo atrapará y en su lugar detiene la ejecución como una excepción no controlada.

Necesita encontrar lo que está causando la salida proceso. Podría ser algo más que una excepción no controlada. Puede intentar usar el depurador nativo con un punto de interrupción establecido en " {,, kernel32.dll} ExitProcess". Luego use SOS para determinar qué código administrado está llamando al proceso de salida.

No entiendo el problema. He descargado y probado su archivo de solución de ejemplo.

Se lanza una excepción en TimeDefLexer.cs, línea 852, que posteriormente es manejada por el bloque catch en el Programa.cs que solo dice Manejó la excepción.

Si descomento el bloque catch encima de él, entrará en ese bloque en su lugar.

¿Cuál parece ser el problema aquí?

Como dijo Kibbee, Visual Studio se detendrá en las excepciones, pero si se le pide que continúe, el la excepción quedará atrapada por su código.

He descargado el proyecto de ejemplo VS2008, y estoy un poco perplejo aquí también. Sin embargo, pude superar las excepciones, aunque probablemente no de una manera que funcione será genial para ti. Pero esto es lo que encontré:

Este post de la lista de correo tuvo una discusión de lo que parece ser el mismo problema que está experimentando.

A partir de ahí, agregué un par de clases ficticias en el programa principal.archivo cs:

class MyNoViableAltException : Exception
{
    public MyNoViableAltException()
    {
    }
    public MyNoViableAltException(string grammarDecisionDescription, int decisionNumber, int stateNumber, Antlr.Runtime.IIntStream input)
    {
    }
}
class MyEarlyExitException : Exception
{
    public MyEarlyExitException()
    {
    }

    public MyEarlyExitException(int decisionNumber, Antlr.Runtime.IIntStream input)
    {
    }
}

Y luego añadimos las líneas using en TimeDefParser.cs y TimeDefLexer.cs:

using NoViableAltException = MyNoViableAltException;
using EarlyExitException = NoViableAltException; 

Con eso, las excepciones se burbujearían en las clases de excepción falsas y podrían manejarse allí, pero todavía había una excepción que se lanzaba en el método mTokens en TimeDefLexer.cs. Envolver eso en un try catch en esa clase atrapó la excepción:

            try
            {
                alt4 = dfa4.Predict(input);
            }
            catch
            {
            }

Realmente no entiendo por qué envolverlo en el método interno en lugar de dónde se está llamando desde manejar el error si el subproceso no está en juego, pero de todos modos espero que eso apunte a alguien más inteligente que yo aquí en la dirección correcta.

He descargado su código y todo funciona como se esperaba.

Visual Studio debugger intercepta correctamente todas las excepciones. Los bloques de captura funcionan como se esperaba.

Estoy ejecutando Windows 2003 server SP2, VS2008 Team Suite (9.0.30729.1 SP)

He intentado compilar su proyecto para. NET 2.0, 3.0 & 3.5

@Steve Steiner, las opciones del depurador que mencionaste no tienen nada que ver con este comportamiento.

Traté de jugar con estas opciones sin efectos visibles-catch los bloques lograron interceptar todas las excepciones.

Steve Steiner tiene razón en que la excepción se origina en la biblioteca antlr, pasando por el método mTokens() y siendo atrapado en la biblioteca antlr. El problema es que este método es autogenerado por antlr. Por lo tanto, cualquier cambio para manejar la excepción en mTokens() se sobrescribirá cuando generes tus clases parser/lexer.

De forma predeterminada, antlr registrará los errores e intentará recuperar el análisis. Puede anular esto para que el analizador sintáctico.prog() lanzará una excepción siempre que se encuentre un error. A partir de su código de ejemplo, creo que este es el comportamiento que esperaba.

Añade este código a tu grammer (.g) expediente. También tendrá que desactivar "Habilitar solo mi código" en el menú de depuración.

@members {

    public override Object RecoverFromMismatchedSet(IIntStream input,RecognitionException e,    BitSet follow)  
    {
        throw e;
    }
}

@rulecatch {
    catch (RecognitionException e) 
    {
        throw e;
    }
}

Este es mi intento de una versión en C# del ejemplo dado en el capítulo "Salir del reconocedor en el primer error" del libro "Referencia Definitiva de ANTLR".

Espero que esto sea lo que estabas buscando.

Puede configurar VS.Net para romper tan pronto como se produce cualquier excepción. Simplemente ejecute su proyecto en modo de depuración, y se detendrá tan pronto como se lance la excepción. Entonces deberías tener una mejor idea de por qué no está siendo atrapado.

También, puede poner algún código en captura todas las excepciones no manejadas. Lee el enlace para más información, pero lo básico son estas dos líneas.

Application.ThreadException += new ThreadExceptionEventHandler(ThreadExceptionHandler);

 // Catch all unhandled exceptions in all threads.
 AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(UnhandledExceptionHandler);

Oh y en referencia a lo que dijo Kibbee; si selecciona Debug|Exceptions en VS y simplemente hace clic en todas las casillas en la columna 'lanzada', debería elegir everythingup AFAIK como una 'excepción de primera oportunidad', es decir, VS indicará cuando la excepción es sobre para ser procesada por todo lo demás y romper el código relevante. Esto debería ayudar con la depuración.

La mejor opción suena como configurar Visual Studio para romper en todas las excepciones no controladas (Debug -> Exceptions dialog, marque la casilla "Common Language Runtime Exceptions" y posiblemente las otras también). A continuación, ejecute el programa en modo de depuración. Cuando el código del analizador sintáctico ANTLR arroja una excepción, Visual Studio debería capturarla y permitirle ver dónde está ocurriendo, el tipo de excepción, etc.

Basado en la descripción, el bloque catch parece ser correcto, por lo que uno de varios las cosas podrían estar sucediendo:

1. el analizador sintáctico no está lanzando una excepción
2. en última instancia, el analizador está lanzando algo que no se deriva del Sistema.Excepción
3. hay una excepción que se lanza en otro hilo que no se está manejando

Parece que has descartado potencialmente el tema #3.

Rastreé a través del conjunto externo con Reflector y no encontré evidencia de roscado en absoluto.

No puedes encontrar ningún roscado no significa que no haya roscado

. NET tiene un 'grupo de subprocesos' que es un conjunto de subprocesos 'de repuesto' que se encuentran en su mayoría inactivos. Ciertos métodos hacen que las cosas se ejecuten en uno de los subprocesos del grupo de subprocesos para que no bloqueen tu aplicación principal.

Los ejemplos evidentes son cosas como ThreadPool.QueueUserWorkItem , pero hay muchas otras cosas que también pueden ejecutar cosas en el grupo de subprocesos que no parecen tan obvias, como Delegate.BeginInvoke

Realmente, necesitas hacer lo que kibbee sugiere.

¿Ha intentado imprimir (Consola.WriteLine ()) la excepción dentro de la cláusula catch, y no usar visual studio y ejecutar la aplicación en la consola?

Creo que Steve Steiner tiene razón. Al investigar las sugerencias de Steve, me encontré con este hilo hablando de la opción "Habilitar solo mi código" en Herramientas|Opciones|Depurador|General. Se sugiere que el depurador se rompa en ciertas condiciones cuando el código no usuario arroja o maneja una excepción. No estoy exactamente seguro de por qué esto siquiera importa, o por qué el depurador dice específicamente que la excepción no fue controlada cuando realmente lo fue.

Fui capaz de eliminar el false se rompe desactivando la opción "Habilitar solo mi código". Esto también cambia el diálogo de depuración / Excepciones al eliminar la columna "manejada por el usuario", ya que ya no se aplica. O bien, puede desmarcar la casilla" manejado por el usuario " para CLR y obtener el mismo resultado.

Muchas gracias por la ayuda a todos!

"También, puede poner un poco de código en captura todas las excepciones no manejadas. Leer el enlace para más información, pero lo básico son estas dos líneas."

Esto es falso. Esto solía capturar todas las excepciones no manejadas en. NET 1.0 / 1.1, pero era un error y no se suponía que lo hiciera y se solucionó en.NET 2.0.

AppDomain.CurrentDomain.UnhandledException 

Solo está destinado a ser utilizado como un salón de registro de última oportunidad para que pueda registrar la excepción antes de que el programa salga. No atrapará la excepción a partir de la 2.0 en adelante (aunque en. NET 2.0 al menos hay un valor de configuración que puede modificar para que actúe como 1.1, pero no se recomienda usar esta práctica.).

Vale la pena señalar que hay pocas excepciones que no puede atrapar, como StackOverflowException y OutOfMemoryException. De lo contrario, como otras personas han sugerido, podría ser una excepción en un hilo de fondo en algún lugar. También estoy bastante seguro de que no puede atrapar algunas/todas las excepciones no administradas/nativas tampoco.

No lo entiendo...tu bloque catch simplemente lanza una nueva excepción (con el mismo mensaje). Lo que significa que su declaración de:

El problema es que en algunos casos (no todos) mi bloque try/catch no lo atrapará y en su lugar detiene la ejecución como una excepción no controlada.

Es exactamente lo que se espera que suceda.

Estoy de acuerdo con Daniel Augery kronoz que esto huele como una excepción que tiene algo que ver con hilos. Más allá de eso, aquí están mis otras preguntas:

1. ¿Qué dice el mensaje de error completo? Qué tipo de excepción es?
2. Basado en el seguimiento de pila que ha proporcionado aquí, no es la excepción lanzada por su código en TimeDefLexer.mTokens ()?

No estoy seguro si no estoy claro, pero si es así, estoy viendo que el depurador detiene la ejecución con una "Excepción no controlada" de tipo NoViableAltException. Inicialmente, no sabía nada sobre este elemento de menú Debug- > Exceptions porque MS espera que, en VS install time, se comprometa a un perfil cuando no tenga idea de cómo son diferentes. Aparentemente, No estaba en el perfil de desarrollo de C# y me faltaba esta opción. Después de finalmente depurar todas las excepciones de CLR lanzadas, desafortunadamente no se puede descubrir ningún comportamiento nuevo que conduzca a la razón de este problema de excepción no controlada. Todas las excepciones lanzadas eran esperadas y supuestamente manejadas en un bloque try / catch.

Revisé el ensamblaje externo y no hay evidencia de multihilo. Con esto, quiero decir que no existe ninguna referencia al Sistema.Roscado y ningún delegado fueron utilizados en absoluto. Estoy familiarizado con que constituye instanciar un hilo. Verifico esto observando la caja de herramientas de hilos en el momento de la excepción no manejada para ver solo hay un subproceso en ejecución.

Tengo un problema abierto con la gente ANTLR así que tal vez han sido capaces de abordar este problema antes. He podido replicarlo en un proyecto de aplicación de consola simple usando. NET 2.0 y 3.5 bajo VS 2008 y VS 2005.

Es solo un punto débil porque obliga a mi código a trabajar solo con una entrada de analizador válida conocida. Usar un método IsValid() sería arriesgado si lanzara una excepción no controlada basada en la entrada del usuario. Voy a mantener esta pregunta se actualiza cuando se aprende más de este tema.

@spoulson,

Si puedes replicarlo, ¿puedes publicarlo en algún lugar? Una avenida que podría probar es usign WinDbg con las extensiones SOS para ejecutar la aplicación y atrapar la excepción no controlada. Se romperá en la excepción de la primera oportunidad (antes de que el tiempo de ejecución intente encontrar un controlador) y se puede ver en ese punto de dónde viene, y qué hilo.

Si no has usado WinDbg antes, puede ser un poco abrumador, pero aquí hay una buena tutorial:

http://blogs.msdn.com/johan/archive/2007/11/13/getting-started-with-windbg-part-i.aspx

Una vez que inicie WinDbg, puede alternar la ruptura de excepciones no controladas yendo a Debug->Event Filters.

Wow, así que de los informes hasta ahora, 2 funcionaron correctamente, y 1 experimentó el problema que informé. ¿Cuáles son las versiones de Windows, Visual Studio utilizadas y. NET framework con números de compilación?

Estoy ejecutando XP SP2, VS 2008 Team Suite (9.0.30729.1 SP), C# 2008 (91899-270-92311015-60837) y.NET 3.5 SP1.

Si está utilizando objetos com su proyecto e intenta capturar bloques no capturar las excepciones, necesitará deshabilitar Herramientas/Depuración/Romper cuando las excepciones crucen AppDomain o límites administrados/nativos(solo administrados) opción.