Warum ist .NET exception nicht gefangen von try/catch-block?

https://stackoverflow.com/questions/36014

09-06-2019
|

Frage

Ich arbeite an einem Projekt mit der ANTLR parser library for C#.Ich habe gebaut eine Grammatik zum Parsen von text und es funktioniert gut.Allerdings, wenn der parser auf eine rechtswidrige oder unerwartetes token, es wirft viele Ausnahmen.Das problem ist, dass in einigen Fällen (nicht alle), dass meine try/catch-block nicht durchsetzen und es stattdessen hält die Ausführung als eine nicht behandelte Ausnahme.

Das Problem für mich ist, dass ich nicht replizieren dieses Problem irgendwo anders, aber in meinem vollständigen code.Die Aufrufliste zeigt, dass die Ausnahme tritt definitiv in meinem try/catch(Exception) blockieren.Das einzige, was ich denken kann, ist, gibt es ein paar ANTLR-Montage Anrufe, die auftreten, zwischen meinem code und dem code auslösen der Ausnahme, und diese Bibliothek nicht Debuggen aktiviert ist, so kann ich nicht Schritt für Schritt durch es.Ich Frage mich, ob nicht-debug-Version einer Baugruppen hemmen Ausnahme sprudelt?Der call-stack sieht wie folgt aus;externe Montage Anrufe werden in Antlr.Laufzeit:

    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#

Das code-snippet, das von der Unterseite-die meisten nennen in der Parse() sieht wie folgt aus:

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

Zu mir, catch (Exception) Klausel sollten erfasst haben jede Ausnahme.Gibt es einen Grund, warum es würde nicht?

Update: Ich verfolgte durch die externe Montage mit Reflektor und fand keine Beweise für threading zu löschen.Die Montage scheint nur eine runtime utility-Klasse für die ANTLR-generierten code.Die Ausnahme, die ausgelöst wird von der TimeDefLexer.mTokens () - Methode und der Typ NoViableAltException, die sich aus RecognitionException -> Exception.Diese Ausnahme wird ausgelöst, wenn der lexer kann nicht verstehen, das nächste token im Strom;in anderen Worten, ungültige Eingabe.Diese Ausnahme SOLL geschehen, jedoch sollte die erwischt wurden durch meine try/catch-block.

Auch das erneute auslösen von ParserException ist wirklich irrelevant für diese situation.Das ist eine Ebene der Abstraktion, die nimmt jede Ausnahme beim Parsen und konvertieren zu meinem eigenen ParserException.Die Ausnahmebehandlung problem, ich bin erfahren wird nie erreichen, dass code-Zeile.In der Tat, ich bemerkte aus den "throw new ParserException" Teil und erhalten das gleiche Ergebnis.

Eine weitere Sache, die ich modifiziert, das original von try/catch-block in Frage, stattdessen fangen NoViableAltException, Beseitigung der Vererbung Verwirrung.Ich habe noch erhalten das gleiche Ergebnis.

Jemand hat einmal vorgeschlagen, dass manchmal VS überaktive Fang behandelt Ausnahmen, wenn im debug-Modus, aber dieses Problem tritt auch dann in den release-Modus.

Mann, ich bin immer noch ratlos!Ich hatte nicht erwähnt, aber ich bin mit VS 2008, und alle meine code ist 3.5.Die externe Montage ist 2.0.Auch einige meiner code Unterklassen einer Klasse in der 2.0-assembly.Könnte eine version mismatch dieses Problem verursachen?

Update 2: Ich war in der Lage zu beseitigen .NET version Konflikten, die durch das portieren, die relevanten Teile meiner .NET 3.5 code ein .NET 2.0-Projekt, und wiederholen Sie das gleiche Szenario.Ich war in der Lage zu replizieren, die die gleichen unbehandelte Ausnahme beim ausführen konsequent .NET 2.0.

Ich habe gelernt, dass ANTLR hat kürzlich veröffentlichten 3.1.Also, ich habe ein Upgrade von der Version 3.0.1 und wiederholt.Es stellt sich heraus, der generierte code ist ein wenig umgestaltet, aber die gleiche nicht behandelte Ausnahme tritt in meine Testfälle.

Update 3: Ich habe repliziert, die dieses Szenario in einem vereinfachte VS 2008-Projekt.Fühlen Sie sich frei zu downloaden und überprüfen Sie das Projekt für sich selbst.Ich habe angewendet, alle die tollen Anregungen, aber nicht in der Lage um dieses Hindernis zu überwinden, doch.

Wenn Sie einen workaround finden, bitte teilen Sie Ihre Erkenntnisse.Nochmals vielen Dank!

Danke, aber VS 2008 automatisch Pausen auf nicht behandelte Ausnahmen.Auch, ich haben keine Debug->Ausnahmen-dialog.Die NoViableAltException geworfen wird, ist vollständig bestimmt, und entwickelt, um sein gefangen durch Benutzercode.Da ist es auch nicht gefangen werden, wie erwartet, wird die Programmausführung Stoppt unerwartet, wie eine nicht behandelte Ausnahme.

Die Ausnahme, die ausgelöst wird abgeleitet von der Ausnahme, und es ist kein multi-threading mit ANTLR.

Lösung

Ich glaube, ich verstehe das problem.Die Ausnahme ist, erwischt zu werden, das Problem ist die Verwirrung über den debugger das Verhalten und die Unterschiede in den debugger-Einstellungen unter jede person, die versucht zu reproduzieren es.

In der 3. Fall von Ihrem repro ich glaube, Sie sind immer folgende Meldung:"NoViableAltException war unhandled by user code" und eine Aufrufliste, die wie folgt aussieht:

         [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]

Wenn Sie mit der rechten klicken Sie auf die callstack-Fenster und führen Sie schalten Sie externen code, den Sie sehen dies:

        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

Der debugger ist die Botschaft der Ihnen mitteilt, dass eine Ausnahme, die Ihren Ursprung außerhalb Ihres code (aus NoViableAlt) wird durch code, den Sie selbst in TestAntlr-3.1.exe!TimeDefLexer.mTokens (), ohne verarbeitet werden.

Die Formulierung ist verwirrend, aber es bedeutet nicht, dass die Ausnahme nicht erfasst.Der debugger wird dich wissen lassen, dass code, den Sie selbst mTokens()" muss robust sein gegen diese Ausnahme ausgelöst wird, durch.

Dinge zu spielen mit, um zu sehen, wie das aussieht für diejenigen, die nicht reproduzierbar das problem:

Gehen Sie zu Extras/Optionen/Debugging und schalten Sie "Enable Just My code (Nur verwaltet)".oder option.
Gehen Sie zu Debugger/Ausnahmen und deaktivieren Sie "Benutzer-nicht behandelte" für Common Language Runtime Exceptions.

Andere Tipps

Unabhängig davon, ob die assembly kompiliert wurde als release-Version, die Ausnahme sollte sicherlich 'bubble' bis zu dem Anrufer, es gibt keinen Grund, eine Versammlung, die nicht kompiliert werden im debug-Modus haben Auswirkungen auf die.

Dem würde ich Zustimmen mit Daniel ist, was darauf hindeutet, dass vielleicht die Ausnahme aufgetreten ist, auf einem separaten thread - versuchen Sie anschließen die thread-Ausnahme-Ereignis in der Anwendung.ThreadException.Dies sollte erhöht werden, wenn jede unhandled thread exception Auftritt.Sie könnte passen Sie Ihren code so:-

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

Sind Sie mit .Net 1.0 oder 1.1?Wenn ja, dann catch(Exception ex) nicht abfangen von Ausnahmen, die von nicht verwaltetem code.Sie brauchen catch {} statt.Lesen Sie diesen Artikel für weitere details:

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

Ich kann Ihnen sagen, was hier passiert...

Visual Studio bricht, weil es denkt, dass die Ausnahme nicht behandelt.Was bedeutet nicht behandelte bedeuten?In Visual Studio gibt es eine Einstellung im Tools -...Optionen...Debugging...General..."Enable Just My Code (nur Verwaltet)".Wenn diese Option aktiviert ist und wenn die Ausnahme propagiert, aus Ihrem code und zu einem stack-frame verbunden mit einem Aufruf der Methode, die besteht in einer Versammlung, die "NICHT-CODE" (z.B. Antlr), welche als "nicht behandelte".Ich ausschalten, die Ermöglichen, dass "Nur Mein Code" - Funktion für diese Grund.Aber, wenn Sie mich Fragen, ist das lame...lassen Sie uns sagen Sie, dies zu tun:

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

doSomething ruft Ihre anonyme Funktion und Funktion eine Ausnahme auslöst...

Beachten Sie, dass dies eine "nicht behandelte Ausnahme" laut Visual Studio, wenn "Enable Just My Code" auf.Beachten Sie auch, dass es Stoppt, wenn es einen Haltepunkt, wenn im debug-Modus, aber in einem nicht-debugging oder Produktion, der code ist vollkommen gültig und funktioniert wie erwartet.Auch, wenn Sie einfach "weiter" in der debugger die app geht auf seine fröhliche Art und Weise (es hört nicht auf den thread).Es wird als "unbehandelte", weil die Ausnahme breitet sich durch stack-Frames, die NICHT in Ihrem code (D. H.in der externen Bibliothek).Wenn Sie mich Fragen, ist das Mies.Bitte ändern dieses Standardverhalten von Microsoft.Dies ist eine vollkommen gültige Falle der Verwendung von Ausnahmen zur Steuerung der Programm-Logik.Manchmal, Sie können nicht ändern die Drittanbieter-Bibliothek zu Verhalten, auf andere Weise, und dies ist ein sehr nützlicher Weg, um zu erreichen viele Aufgaben.

Nehmen MyBatis zum Beispiel, können Sie diese Technik verwenden, um zu stoppen Verarbeitung der Datensätze, die gesammelt werden durch einen Aufruf von SqlMapper.QueryWithRowDelegate.

Ist es möglich, dass die exception geworfen wird, in einem anderen thread?Offensichtlich geht der aufrufende code ist single-threaded, aber vielleicht ist die Bibliothek, auf die Sie konsumieren dabei einige Multithread-Operationen unter der Decke.

Ich bin mit @Shaun Austin - versuchen, Verpackung die versuche mit den voll qualifizierten Namen

catch (System.Exception)

und sehen, ob das hilft.Hat der ANTLR-doc sagen, was Ausnahmen geworfen werden sollte?

Zu mir, catch (Exception) Klausel sollten erfasst haben jede Ausnahme.Gibt es einen Grund, warum es würde nicht?

Die einzige Möglichkeit, die ich denken kann, ist, etwas anderes zu fangen, bevor Sie und der Handhabung in einer Weise, die scheint, eine nicht abgefangene Ausnahme ausgelöst wird (z.B.beenden Sie den Prozess).

meine try/catch-block nicht durchsetzen und es stattdessen hält die Ausführung als eine nicht behandelte Ausnahme.

Sie müssen herausfinden, was die Ursache für den Ausstieg.Es könnte etwas anderes sein als eine nicht behandelte Ausnahme.Sie könnten versuchen, mithilfe der systemeigenen debugger einen breakpoint auf "{,,kernel32.dll}ExitProcess".Verwenden Sie dann SOS um zu bestimmen, welche verwalteten code aufrufen exit-Prozess.

Ich persönlich bin nicht davon überzeugt, das threading-Theorie überhaupt.

Das eine mal, ich habe gesehen, dies vor, ich arbeite mit einer Bibliothek, die auch definierte Ausnahme und das aufzuhalten der Benutzung hatte ich gedacht, dass die tatsächlichen Fangmengen bezog sich auf ein anderes "Ausnahme" Typ (wenn es vollständig qualifizierte, war es Unternehmen.Lib.Ausnahme aber es war nicht wegen der Verwendung), so dass, wenn kam es zu fangen eine normale Ausnahme wurde geworfen werden (eine Art von argument-Ausnahme, wenn ich mich richtig erinnere), wäre es nicht fangen, weil der Typ nicht übereinstimmen.

So in der Zusammenfassung, ist es eine andere Exception-Typ in einen anderen namespace, der in einer Verwendung, die in dieser Klasse?

EDIT:Ein schneller Weg, um dies zu überprüfen, ist sicherzustellen, dass in Ihrem catch-Klausel, die Sie vollständig zu qualifizieren die Ausnahme als Typ "System.Ausnahme" und geben Sie es ein whirl!

EDIT2:OK, ich habe versucht, den code und die Niederlage eingestehen jetzt.Ich muss einen Blick auf es in die morgen, wenn niemand zu einer Lösung zu kommen.

Hmm, ich verstehe nicht das problem.Ich heruntergeladen und versucht, Ihre Beispiel-Lösung-Datei.

Eine Ausnahme wird geworfen in TimeDefLexer.cs, line 852, die anschließend bearbeitet durch die catch-block im Programm.cs, der nur sagt, Ausnahme behandelt.

Wenn ich kommentieren Sie die catch-block oben sind, wird es geben Sie, dass block statt.

Was scheint hier das problem?

Als Kibbee gesagt, Visual Studio Anschlag auf Ausnahmen, aber wenn Sie Sie bitten, es auch weiter, die exception wird gefangen von Ihrem code.

Ich habe die Beispiel-VS2008-Projekt, und bin ein bisschen ratlos auch hier.Ich war in der Lage zu bekommen Vergangenheit die Ausnahmen, wenn auch wahrscheinlich nicht in einer Weise, die Arbeit wird für Sie groß.Aber hier ist was ich gefunden habe:

Diese mailing-Liste-post hatte eine Diskussion darüber, was aussieht, um das gleiche Problem bei Ihnen Auftritt.

Von dort habe ich noch ein paar dummy-Klassen in das Hauptprogramm.cs-Datei:

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

und dann die Verwendung von Linien in TimeDefParser.cs und TimeDefLexer.cs:

using NoViableAltException = MyNoViableAltException;
using EarlyExitException = NoViableAltException;

Mit die Ausnahmen würden Blase in die fake-exception-Klassen und gehandhabt werden kann es, aber es war immer noch eine Ausnahme ausgelöst wird, in der mTokens Methode in TimeDefLexer.cs.Verpackung, die in einem try-catch in die Klasse fing die Ausnahme:

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

Ich weiß wirklich nicht, warum die den Umschlag in der internen Methode statt, wo es aufgerufen wird, aus den Fehler behandeln, wenn threading ist nicht im Spiel, aber trotzdem hoffentlich zeigen wird jemand schlauer als ich hier in die richtige Richtung.

Ich habe Ihre code und alles funktioniert wie erwartet.

Visual Studio-debugger korrekt fängt alle Ausnahmen.Catch-Blöcke wie erwartet funktionieren.

Ich bin mit Windows 2003 server SP2, VS2008 Team Suite (9.0.30729.1 SP)

Ich habe versucht zu kompilieren Projekt für Sie .NET 2.0, 3.0 & 3.5

@Steve Steiner, debugger-Optionen, die Sie erwähnt haben nichts zu tun mit diesem Verhalten.

Ich habe versucht zu spielen mit diesen Optionen mit keine sichtbaren Effekte - catch-Blöcken verwaltet, um zu fangen alle Ausnahmen.

Steve Steiner ist richtig, dass das die Ausnahme ist, die Ihren Ursprung in der antlr-Bibliothek, die durch den mTokens () - Methode und gefangen in der antlr-Bibliothek.Das problem ist, dass diese Methode ist auto-generated by antlr.Daher, werden alle änderungen, die Ausnahme behandeln in mTokens() überschrieben wird, wenn Sie Ihre erstellen Sie Ihre parser/lexer Klassen.

Standardmäßig antlr-log-Fehler und versuchen, sich zu erholen analysieren.Sie können dies überschreiben, so dass der parser.prog() wird eine Ausnahme ausgelöst, wenn ein Fehler aufgetreten ist.Aus deinem Beispiel-code, den ich denke, dies ist das Verhalten, die Sie erwartet hatten.

Fügen Sie diesen code zu Ihrem grammer (.g) - Datei.Sie müssen auch schalten Sie "Enable Just My Code" im Debuggen-Menü.

@members {

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

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

Dies ist mein Versuch einer C# - version im Beispiel im Abschnitt "Beenden der recogniser auf den ersten Fehler" Kapitel von "die Endgültige ANTLR-Referenz" - Buch.

Hoffe, das ist, was Sie gesucht haben.

Sie können set up VS.Net zu brechen, sobald eine Ausnahme Auftritt.Führen Sie einfach Ihr Projekt im debug-Modus, und es wird aufhören, sobald die exception geworfen wird.Dann sollten Sie eine bessere Vorstellung davon, warum es nicht gefangen werden.

Auch, Sie können setzen einige code in fangen Sie alle nicht behandelten Ausnahmen.Lesen Sie den link für weitere Informationen, aber die Grundlagen sind diese zwei Linien.

Application.ThreadException += new ThreadExceptionEventHandler(ThreadExceptionHandler);

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

Oh, und in Bezug darauf, was Kibbee sagte;wenn Sie wählen Sie Debuggen|Ausnahmen in VS und klicken Sie einfach auf alle Felder in der 'geworfen' Spalte, Sie sollte pick alles bis AFAIK als "erste-chance-Ausnahme', D. H.VS zeigt an, wenn die Ausnahme ist über die Verarbeitung alles andere und brechen auf den entsprechenden code.Dies hilft bei der Fehlerbehebung.

Die beste option klingt, wie Sie Visual Studio zu brechen, auf alle nicht behandelten Ausnahmen (Debug -> Ausnahmen-dialog, aktivieren Sie das Kontrollkästchen für "Common Language Runtime Exceptions" und vielleicht die anderen auch).Führen Sie dann Ihr Programm im debug-Modus.Wenn Sie die ANTLR-parser-code eine Ausnahme auslöst, sollte er gefangen werden, die von Visual Studio und ermöglicht Ihnen zu sehen, wo Sie Auftritt, den Typ der Ausnahme, etc.

Basierend auf der Beschreibung, wird der catch-block richtig zu sein scheint, so dass man mehrere Dinge passieren:

der parser ist nicht wirklich eine Ausnahme zu werfen
der parser ist letztlich wirft etwas, das nicht der Ableitung aus dem System.Ausnahme
es wird eine Ausnahme ausgelöst wird, in einem anderen thread, der nicht behandelt wird

Es klingt wie Sie möglicherweise ausgeschlossen issue #3.

Ich verfolgte durch die externe Montage mit Reflektor und fand keine Beweise für threading zu löschen.

Sie finden keine threading bedeutet nicht, dass es keine threading

.NET hat ein "thread-pool", die eine Reihe von "Reserve" - threads, die sitzen meist im Leerlauf.Bestimmte Methoden bewirken, dass die Dinge laufen in der thread-pool-threads, so dass Sie nicht block Ihre Haupt-app.

Eklatante Beispiele sind Dinge wie ThreadPool.QueueUserWorkItem, aber es gibt viele andere Dinge, die auch Dinge, die im thread-pool, don ' T look so offensichtlich wie Delegieren.BeginInvoke

Wirklich, Sie brauchen, um tun, was kibbee schlägt.

Sie haben versucht zu drucken (- Konsole.WriteLine () die exception innerhalb des catch-Klausel, und nicht verwenden Sie visual studio, und führen Sie Ihre Anwendung auf der Konsole?

Ich glaube, dass Steve Steiner korrekt ist.Bei der recherche Steve Anregungen, stieß ich auf dieser thread reden über die "Enable Just My Code" option in Tools|Optionen|Debugger|General.Es wird vorgeschlagen, dass der debugger Pause in bestimmten Bedingungen, wenn Sie nicht Benutzer-code entweder wirft oder eine Ausnahme behandelt.Ich bin mir nicht ganz sicher, warum dies überhaupt wichtig ist, oder warum der debugger sagt ausdrücklich Ausnahme war nicht behandelte, als es wirklich war.

Ich war in der Lage zu beseitigen die falschen Pausen, indem Sie die "Enable Just My Code" option.Dadurch ändert sich auch die Debug|Exceptions-dialog durch das entfernen des "User-behandelt" - Spalte, da es nicht mehr gilt.Oder, Sie können einfach deaktivieren Sie das Kontrollkästchen "Benutzer-behandelt" - box für CLR und das gleiche Ergebnis erhalten.

Bigtime vielen Dank für die Hilfe an alle!

"Auch, Sie können setzen einige code in fangen Sie alle Ausnahmen.Lesen die link für weitere Infos, aber die Grundlagen sind diese beiden Zeilen."

Das ist falsch.Diese benutzt, um zu fangen alle nicht behandelten Ausnahmen in .NET 1.0/1.1, aber es war ein Fehler und es war nicht vorgesehen, und es wurde behoben .NET 2.0.

AppDomain.CurrentDomain.UnhandledException

Nur soll verwendet werden als eine Letzte chance Protokollierung Salon so können Sie log die Ausnahme, bevor das Programm beendet.Es wird nicht fangen Sie die Ausnahme ab 2.0 ab (obwohl in der .NET 2.0 gibt es zumindest eine Einstellung, die Sie ändern können, um Sie zu handeln, wie 1.1, aber es ist nicht empfohlen zu verwenden Sie diese.).

Es ist erwähnenswert, dass es gibt nur wenige Ausnahmen, die Sie nicht fangen, wie StackOverflowException und OutOfMemoryException.Anders als andere Leute haben vorgeschlagen, könnte es eine Ausnahme in einem hintergrund-thread irgendwo.Auch ich bin mir ziemlich sicher, Sie können nicht fangen einige/alle unmanaged/native Ausnahmen.

Ich verstehe es nicht...Ihr catch-block wirft eine neue Ausnahme (mit der gleichen Meldung).Was bedeutet, dass Ihre Aussage:

Das problem ist, dass in einigen Fällen (nicht alle), dass meine try/catch-block nicht durchsetzen und es stattdessen hält die Ausführung als eine nicht behandelte Ausnahme.

ist genau das, was ist erwartet geschehen.

Ich Stimme mit Daniel Auger und kronoz dass dies riecht wie eine Ausnahme, die hat etwas zu tun mit threads.Darüber hinaus, sind hier meine weiteren Fragen:

Was bedeutet die vollständige Fehlermeldung sagen?Welche Art von Ausnahme ist es?
Basierend auf dem stack-trace haben Sie zur Verfügung gestellt hier, ist nicht die Ausnahme ausgelöst, indem Sie den code in TimeDefLexer.mTokens()?

Ich bin nicht sicher, wenn ich mich unklar zu sein, aber wenn es so ist, sehe ich den debugger angehalten werden, die mit "nicht Behandelte Ausnahme" der Typ NoViableAltException.Zunächst wusste ich gar nichts über diese Debug->Ausnahmen Menüpunkt weil MS erwartet Sie, bei VS zu installieren, Zeit, sich zu verpflichten, ein Profil, wenn Sie keine Ahnung haben, wie Sie anders sind.Offenbar, Ich war nicht auf der C# - dev-Profil und fehlte diese option.Nachdem endlich alle debugging-geworfen CLR-Ausnahmen, ich war leider nicht in der Lage zu entdecken, neue Verhaltensweisen führt, um den Grund für dieses Problem unbehandelte Ausnahme.Alle Ausnahmen, die erwartet wurden, und angeblich behandelt werden, in einen try/catch-block.

Ich überprüfte die externe Montage-und es gibt keine Beweise für multithreading.Damit meine ich keine Referenz vorhanden ist, um die System.Threading und keine Delegierten benutzt wurden, zu löschen.Ich bin vertraut mit, der darstellt, instanziieren Sie einen thread.Ich bestätige dies durch die Beobachtung des Threads toolbox zum Zeitpunkt der unbehandelte Ausnahme view gibt es nur eine thread ausgeführt.

Ich habe eine offene Frage, mit der ANTLR-Leute, so Sie vielleicht in der Lage gewesen, etwas gegen dieses Problem vor.Ich habe in der Lage zu replizieren, die es in einem einfachen Konsolen-app-Projekt mit .NET 2.0 und 3.5 unter VS 2008 und VS 2005.

Es ist nur ein Schmerz, weil es zwingt, meinen code zu arbeiten nur mit bekannten, gültigen parser-Eingang.Mit einem IsValid() Methode würde riskant sein, wenn es warf eine nicht behandelte Ausnahme basierend auf Benutzereingaben.Ich halte diese Frage aktuell, wenn mehr gelernt wird dieses Problem.

@spoulson,

Wenn Sie replizieren, können Sie diese irgendwo veröffentlichen?Eine Allee, die Sie könnten versuchen, ist usign WinDBG mit der SOS-Erweiterungen, die zum ausführen der app und fangen Sie das unbehandelte Ausnahme.Sie brechen auf die erste chance-Ausnahme (bevor die Laufzeitumgebung versucht, einen handler) und Sie können sehen, an diesem Punkt, wo es herkommt, und was-thread.

Wenn Sie noch nicht verwendet WinDBG vor, kann es ein wenig überwältigend, aber hier ist ein gutes tutorial:

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

Sobald Sie starten Sie WinDBG, Sie können Umschalten, die brechen nicht behandelte Ausnahmen, gehen Sie zu Debug->Event-Filter.

Wow, so die Berichte, so weit, 2 richtig gearbeitet, und 1 erlebte ich ein Problem gemeldet.Was sind die Versionen von Windows, Visual Studio verwendet, und .NET framework mit build-Nummern?

Ich bin mit XP SP2, VS 2008 Team Suite (9.0.30729.1 SP), C# 2008 (91899-270-92311015-60837), und .NET 3.5 SP1.

Wenn Sie com-Objekte Ihres Projekts und versuchen Sie catch-Blöcke nicht fangen die Ausnahmen werden Sie brauchen, deaktivieren Sie Extras/Debugging/Pause, wenn Ausnahmen cross AppDomain oder managed/native Grenzen(nur Verwaltet) option.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow