¿Por qué el bloque try/catch no detecta la excepción .NET?

StackOverflow https://stackoverflow.com/questions/36014

  •  09-06-2019
  •  | 
  •  

Pregunta

Estoy trabajando en un proyecto usando el antlr Biblioteca de analizador para C#.Creé una gramática para analizar texto y funciona bien.Sin embargo, cuando el analizador encuentra un token ilegal o inesperado, genera una de muchas excepciones.El problema es que en algunos casos (no en todos) mi bloque try/catch no lo detecta y, en cambio, detiene la ejecución como una excepción no controlada.

El problema para mí es que no puedo replicar este problema en ningún otro lugar que no sea mi código completo.La pila de llamadas muestra que la excepción definitivamente ocurre dentro de mi bloque try/catch(Exception).Lo único que se me ocurre es que hay algunas llamadas de ensamblaje ANTLR que ocurren entre mi código y el código que genera la excepción y esta biblioteca no tiene la depuración habilitada, por lo que no puedo recorrerla.Me pregunto si los ensamblados no depurables inhiben la propagación de excepciones.La pila de llamadas tiene este aspecto;las llamadas de ensamblado externo están en Antlr.Runtime:

    Expl.Itinerary.dll!TimeDefLexer.mTokens() Line 1213 C#
    Antlr3.Runtime.dll!Antlr.Runtime.Lexer.NextToken() + 0xfc bytes 
    Antlr3.Runtime.dll!Antlr.Runtime.CommonTokenStream.FillBuffer() + 0x22c bytes   
    Antlr3.Runtime.dll!Antlr.Runtime.CommonTokenStream.LT(int k = 1) + 0x68 bytes
    Expl.Itinerary.dll!TimeDefParser.prog() Line 109 + 0x17 bytes   C#
    Expl.Itinerary.dll!Expl.Itinerary.TDLParser.Parse(string Text = "", Expl.Itinerary.IItinerary Itinerary = {Expl.Itinerary.MemoryItinerary}) Line 17 + 0xa bytes C#

El fragmento de código de la llamada inferior en Parse() tiene este aspecto:

     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);
     }

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?

Actualizar: Revisé el conjunto externo con Reflector y no encontré evidencia de rosca alguna.El ensamblado parece ser simplemente una clase de utilidad en tiempo de ejecución para el código generado por ANTLR.La excepción lanzada es del método TimeDefLexer.mTokens() y su tipo es NoViableAltException, que deriva de RecognitionException -> Exception.Esta excepción se produce cuando el lexer no puede comprender el siguiente token de la secuencia;en otras palabras, entrada no válida.Se SUPONE que esta excepción debe ocurrir, sin embargo, debería haber sido detectada por mi bloque try/catch.

Además, volver a lanzar ParserException es realmente irrelevante para esta situación.Esa es una capa de abstracción que toma cualquier excepción durante el análisis y la convierte en mi propia ParserException.El problema de manejo de excepciones que estoy experimentando es que nunca llega a esa línea de código.De hecho, comenté la parte "lanzar nueva excepción ParserException" y todavía recibí el mismo resultado.

Una cosa más, modifiqué el bloque try/catch original en cuestión para capturar NoViableAltException, eliminando cualquier confusión de herencia.Todavía recibí el mismo resultado.

Alguien sugirió una vez que a veces VS es hiperactivo al detectar excepciones manejadas cuando está en modo de depuración, pero este problema también ocurre en el modo de lanzamiento.

¡Hombre, todavía estoy perplejo!No lo había mencionado antes, pero estoy ejecutando VS 2008 y todo mi código es 3.5.El ensamblaje externo es 2.0.Además, parte de mi código subclasifica una clase en el ensamblado 2.0.¿Podría una discrepancia de versión causar este problema?

Actualización 2: Pude eliminar el conflicto de la versión .NET transfiriendo partes relevantes de mi código .NET 3.5 a un proyecto .NET 2.0 y replicando el mismo escenario.Pude replicar la misma excepción no controlada cuando ejecuté consistentemente .NET 2.0.

Me enteré de que ANTLR lanzó recientemente la versión 3.1.Entonces, actualicé desde 3.0.1 y lo volví a intentar.Resulta que el código generado está un poco refactorizado, pero ocurre la misma excepción no controlada en mis casos de prueba.

Actualización 3:He replicado este escenario en un proyecto VS 2008 simplificado.No dude en descargar e inspeccionar el proyecto usted mismo.He aplicado todas las excelentes sugerencias, pero aún no he podido superar este obstáculo.

Si puede encontrar una solución alternativa, comparta sus hallazgos.¡Gracias de nuevo!

Gracias, pero VS 2008 falla automáticamente ante excepciones no controladas.Además, no tengo un cuadro de diálogo Depurar->Excepciones.La NoViableAltException que se lanza está totalmente pensada y diseñada para ser detectada por el código de usuario.Dado que no se detecta como se esperaba, la ejecución del programa se detiene inesperadamente como una excepción no controlada.

La excepción lanzada se deriva de Exception y no hay subprocesos múltiples con ANTLR.

¿Fue útil?

Solución

Creo que entiendo el problema.La excepción es ser detectada, el problema es la confusión sobre el comportamiento del depurador y las diferencias en la configuración del depurador entre cada persona que intenta reproducirlo.

En el tercer caso de su reproducción, creo que recibe el siguiente mensaje:"NoViableAltException no fue manejada por el código de usuario" y una pila de llamadas que se ve así:

         [External Code]    
    >   TestAntlr-3.1.exe!TimeDefLexer.mTokens() Line 852 + 0xe bytes   C#
        [External Code] 
        TestAntlr-3.1.exe!TimeDefParser.prog() Line 141 + 0x14 bytes    C#
        TestAntlr-3.1.exe!TestAntlr_3._1.Program.ParseTest(string Text = "foobar;") Line 49 + 0x9 bytes C#
        TestAntlr-3.1.exe!TestAntlr_3._1.Program.Main(string[] args = {string[0x00000000]}) Line 30 + 0xb bytes C#
        [External Code]

Si hace clic derecho en la ventana de la pila de llamadas y ejecuta activar mostrar código externo, verá esto:

        Antlr3.Runtime.dll!Antlr.Runtime.DFA.NoViableAlt(int s = 0x00000000, Antlr.Runtime.IIntStream input = {Antlr.Runtime.ANTLRStringStream}) + 0x80 bytes   
        Antlr3.Runtime.dll!Antlr.Runtime.DFA.Predict(Antlr.Runtime.IIntStream input = {Antlr.Runtime.ANTLRStringStream}) + 0x21e bytes  
    >   TestAntlr-3.1.exe!TimeDefLexer.mTokens() Line 852 + 0xe bytes   C#
        Antlr3.Runtime.dll!Antlr.Runtime.Lexer.NextToken() + 0xc4 bytes 
        Antlr3.Runtime.dll!Antlr.Runtime.CommonTokenStream.FillBuffer() + 0x147 bytes   
        Antlr3.Runtime.dll!Antlr.Runtime.CommonTokenStream.LT(int k = 0x00000001) + 0x2d bytes  
        TestAntlr-3.1.exe!TimeDefParser.prog() Line 141 + 0x14 bytes    C#
        TestAntlr-3.1.exe!TestAntlr_3._1.Program.ParseTest(string Text = "foobar;") Line 49 + 0x9 bytes C#
        TestAntlr-3.1.exe!TestAntlr_3._1.Program.Main(string[] args = {string[0x00000000]}) Line 30 + 0xb bytes C#
        [Native to Managed Transition]  
        [Managed to Native Transition]  
        mscorlib.dll!System.AppDomain.ExecuteAssembly(string assemblyFile, System.Security.Policy.Evidence assemblySecurity, string[] args) + 0x39 bytes    
        Microsoft.VisualStudio.HostingProcess.Utilities.dll!Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly() + 0x2b bytes  
        mscorlib.dll!System.Threading.ThreadHelper.ThreadStart_Context(object state) + 0x3b bytes   
        mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state) + 0x81 bytes    
        mscorlib.dll!System.Threading.ThreadHelper.ThreadStart() + 0x40 bytes

El mensaje del depurador le indica que una excepción que se origina fuera de su código (de NoViableAlt) está pasando por el código que posee en TestAntlr-3.1.exe!TimeDefLexer.mTokens() sin ser manejada.

La redacción es confusa, pero no significa que la excepción no se detecte.El depurador le permite saber que el código que posee mTokens()" debe ser robusto contra esta excepción que se genera a través de él.

Cosas con las que jugar para ver cómo se ve esto para aquellos que no reprodujeron el problema:

  • Vaya a herramientas/opciones/depuración y apague "Habilite solo mi código (solo administrado)".u opción.
  • Vaya a depurador/excepciones y desactive "no controlado por el usuario" para excepciones de tiempo de ejecución en común.

Otros consejos

Independientemente de si el ensamblado se ha compilado como una versión de lanzamiento, la excepción ciertamente debería "aparecer" en la persona que llama, no hay ninguna razón por la que un ensamblado que no se compila en modo de depuración deba tener algún efecto en eso.

Estoy de acuerdo con que Daniel sugiere que tal vez la excepción esté ocurriendo en un hilo separado; intente conectar el evento de excepción del hilo en Application.ThreadException.Esto debe generarse cuando se produce cualquier excepción de subproceso no controlado.Podrías adaptar tu 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;
 }

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

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

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

Visual Studio falla porque cree que la excepción no está controlada.¿Qué significa sin manejar?Bueno, en Visual Studio, hay una configuración en Herramientas...Opciones...Depurando...General..."Habilitar Solo mi código (solo administrado)".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), eso se considera "no controlado".Desactivo la función Habilitar solo mi código por este motivo.Pero, si me preguntas, esto es tonto...digamos que haces esto:

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

doSomething llama a tu función anónima allí y esa función arroja una excepción...

Tenga en cuenta que se trata de una "excepción no controlada" según 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 de producción o sin depuración, el código es perfectamente válido y funciona como se esperaba.Además, si simplemente "continúa" en el depurador, la aplicación continúa alegremente (no detiene el hilo).Se considera "no controlado" 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.Cambie este comportamiento predeterminado Microsoft.Este es un caso perfectamente válido de uso de excepciones para controlar la lógica del programa.A veces, no se puede cambiar la biblioteca de terceros para que se comporte de otra manera, y esta es una forma muy útil de realizar muchas tareas.

Tome MyBatis, por ejemplo, puede utilizar esta técnica para detener el procesamiento de registros que se recopilan mediante una llamada a SqlMapper.QueryWithRowDelegate.

¿Es posible que la excepción se esté lanzando en otro hilo?Obviamente, su código de llamada es de un solo subproceso, pero tal vez la biblioteca que está consumiendo esté realizando algunas operaciones multiproceso en secreto.

Estoy con @Shaun Austin: intente completar el intento con el nombre completo

catch (System.Exception)

y vea si eso ayuda. ¿El documento ANTLR dice qué excepciones se deben lanzar?

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 que se me ocurre es que algo más lo esté detectando antes que usted y manejándolo de una manera que parezca ser una excepción no detectada (p. ej.salir del proceso).

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

Necesita encontrar qué está causando el proceso de salida.Podría ser algo más que una excepción no controlada.Puede intentar utilizar el depurador nativo con un punto de interrupción establecido en "{,,kernel32.dll}ExitProcess".Entonces usa LLAMADA DE SOCORRO para determinar qué código administrado llama al proceso de salida.

Personalmente, la teoría del hilo no me convence en absoluto.

La única vez que vi esto antes, estaba trabajando con una biblioteca que también definía Excepción y los usos que tenía significaban que la Captura real se refería a un tipo de "Excepción" diferente (si hubiera sido completamente calificado, era Compañía. Lib.Exception pero no fue por el uso), por lo que cuando se trataba de detectar una excepción normal que se estaba lanzando (algún tipo de excepción de argumento, si no recuerdo mal), simplemente no la detectaba porque el tipo no coincidía.

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

EDITAR:Una forma rápida de verificar esto es asegurarse de que en su cláusula catch califique completamente el tipo de excepción como "System.Exception" y ¡pruébelo!

EDITAR2:OK, probé el código y admito la derrota por ahora.Tendré que echarle otro vistazo por la mañana si a nadie se le ocurre una solución.

Mmmm, no entiendo el problema.Descargué y probé su archivo de solución de ejemplo.

Se produce una excepción en TimeDefLexer.cs, línea 852, que posteriormente es manejada por el bloque catch en Program.cs que simplemente dice excepción manejada.

Si descomento el bloque catch que se encuentra encima, ingresará a ese bloque.

Qué es lo que parece ser el problema aquí?

Como dijo Kibbee, Visual Studio se detendrá ante las excepciones, pero si le pide que continúe, su código detectará la excepción.

Descargué el proyecto de muestra VS2008 y aquí también estoy un poco perplejo.Sin embargo, pude superar las excepciones, aunque probablemente no de una manera que funcione bien para usted.Pero esto es lo que encontré:

Este publicación en la lista de correo Tuve una discusión sobre lo que parece ser el mismo problema que usted está experimentando.

A partir de ahí, agregué un par de clases ficticias en el archivo principal program.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 agregó las líneas de uso en TimeDefParser.cs y TimeDefLexer.cs:

using NoViableAltException = MyNoViableAltException;
using EarlyExitException = NoViableAltException;

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

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

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

Descargué tu código y todo funciona como se esperaba.

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

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

Intenté compilar tu proyecto para .NET 2.0, 3.0 y 3.5

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

Intenté jugar con estas opciones sin efectos visibles: los bloques catch lograron interceptar todas las excepciones.

Steve Steiner tiene razón en que la excepción se origina en la biblioteca antlr, pasa por el método mTokens() y queda atrapada en la biblioteca antlr.El problema es que este método lo genera automáticamente antlr.Por lo tanto, cualquier cambio para manejar la excepción en mTokens() se sobrescribirá cuando genere sus clases de analizador/lexer.

De forma predeterminada, antlr registrará los errores e intentará recuperar el análisis.Puede anular esto para que parser.prog() arroje una excepción cada vez que se encuentre un error.Por su código de ejemplo, creo que este es el comportamiento que esperaba.

Agregue este código a su archivo de gramática (.g).También deberá 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 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 que se interrumpa tan pronto como se produzca una excepción.Simplemente ejecute su proyecto en modo de depuración y se detendrá tan pronto como se produzca la excepción.Entonces deberías tener una mejor idea de por qué no lo detectan.

Además, puedes poner algo de código en capturar todas las excepciones no controladas.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);

Ah, y en referencia a lo que dijo Kibbee;si selecciona Depurar|Excepciones en VS y simplemente hace clic en todas las casillas en la columna 'lanzada', debería seleccionar todo plantear a AFAIK como una 'excepción de primera oportunidad', es decirVS indicará cuando la excepción es acerca de para ser procesado por todo lo demás y romper en el código relevante.Esto debería ayudar con la depuración.

La mejor opción suena como configurar Visual Studio para que interrumpa todas las excepciones no controladas (cuadro de diálogo Depurar -> Excepciones, marque la casilla "Excepciones de Common Language Runtime" y posiblemente también las demás).Luego ejecute su programa en modo de depuración.Cuando el código del analizador ANTLR arroja una excepción, Visual Studio debería detectarla y permitirle ver dónde está ocurriendo, el tipo de excepción, etc.

Según la descripción, el bloque catch parece ser correcto, por lo que podrían estar sucediendo una de varias cosas:

  1. el analizador en realidad no está lanzando una excepción
  2. el analizador finalmente arroja algo que no se deriva de System.Exception
  3. se lanza una excepción en otro hilo que no se está manejando

Parece que potencialmente has descartado el problema número 3.

Revisé el conjunto externo con Reflector y no encontré evidencia de rosca alguna.

No puedes encontrar ningún subproceso, no significa que no haya subprocesos.

.NET tiene un "grupo de subprocesos", que es un conjunto de subprocesos "de repuesto" que permanecen inactivos.Ciertos métodos hacen que las cosas se ejecuten en uno de los subprocesos del grupo de subprocesos para que no bloqueen su aplicación principal.

Los ejemplos flagrantes son cosas como ThreadPool.QueueUserWorkItem, pero hay muchísimas otras cosas que también pueden ejecutar cosas en el grupo de subprocesos que no parecen tan obvias, como Delegar.BeginInvoke

De verdad, necesitas haz lo que sugiere kibbee.

¿Has intentado imprimir (Console.WriteLine()) la excepción dentro de la cláusula catch y no usar Visual Studio y ejecutar tu aplicación en la consola?

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

Pude eliminar las interrupciones falsas desactivando la opción "Habilitar solo mi código".Esto también cambia el cuadro de diálogo Depurar|Excepciones al eliminar la columna "Manejado por el usuario", ya que ya no se aplica.O simplemente puede desmarcar la casilla "Manejado por el usuario" para CLR y obtener el mismo resultado.

¡Muchas gracias por la ayuda a todos!

"Además, puede poner algún código para atrapar todas las excepciones no controladas.Lea el enlace para obtener más información, pero los conceptos básicos son estas dos líneas ".

Esto es falso.Esto solía detectar todas las excepciones no controladas 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 salón de registro de última oportunidad para que pueda registrar la excepción antes de que salga el programa.No detectará la excepción a partir de 2.0 (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 utilizarlo).

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

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

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

es exactamente lo que es esperado que suceda.

estoy de acuerdo con Daniel Auger y corona que esto huele a 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. Según el seguimiento de la pila que proporcionó aquí, ¿no es la excepción lanzada por su código en TimeDefLexer.mTokens()?

No estoy seguro de no estar siendo claro, pero si es así, veo que el depurador detiene la ejecución con una "Excepción no controlada" de tipo NoViableAltException.Inicialmente, no sabía nada sobre este elemento del menú Depurar->Excepciones porque MS espera que usted, en el momento de la instalación de VS, se comprometa con un perfil cuando no tiene idea de en qué se diferencian.Aparentemente, No estaba en el perfil de desarrollo de C# y me faltaba esta opción.Después de depurar finalmente todas las excepciones CLR lanzadas, desafortunadamente no pude descubrir ningún comportamiento nuevo que condujera al motivo 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 subprocesos múltiples.Con esto quiero decir que no existe ninguna referencia a System.Threading y no se utilizó ningún delegado.Estoy familiarizado con eso que constituye crear una instancia de un hilo.Verifico esto observando la caja de herramientas Subprocesos en el momento de la excepción no controlada para ver que solo hay un subproceso en ejecución.

Tengo un problema abierto con la gente de ANTLR, así que tal vez hayan podido abordarlo antes.Pude replicarlo en un proyecto de aplicación de consola simple usando .NET 2.0 y 3.5 en VS 2008 y VS 2005.

Es solo un problema porque obliga a mi código a funcionar solo con entradas válidas conocidas del analizador.Usando un IsValid() El método sería arriesgado si arrojara una excepción no controlada basada en la entrada del usuario.Mantendré esta pregunta actualizada cuando sepamos más sobre este problema.

@spoulson,

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

Si no ha usado WinDBG antes, puede resultar un poco abrumador, pero aquí tiene un buen 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 interrupción de excepciones no controladas yendo a Depurar->Filtros de eventos.

Vaya, 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 en su proyecto e intenta capturar bloques para no detectar las excepciones, deberá desactivar la opción Herramientas/Depuración/Interrupción cuando las excepciones crucen el dominio de aplicación o los límites administrados/nativos (solo administrados).

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top