2013-08-06 3 views
39

Wenn ein Debugger an einen .NET-Prozess angehängt ist, stoppt er (normalerweise), wenn eine nicht behandelte Ausnahme ausgelöst wird.Debugger für Exceptions in der asynchronen Methode nicht unterbrochen/gestoppt

Allerdings scheint dies nicht zu funktionieren, wenn Sie in einer async Methode sind.

Die Szenarien habe ich versucht, bevor in den folgenden Code aufgeführt sind:

class Program 
{ 
    static void Main() 
    { 
     // Debugger stopps correctly 
     Task.Run(() => SyncOp()); 

     // Debugger doesn't stop 
     Task.Run(async() => SyncOp()); 

     // Debugger doesn't stop 
     Task.Run((Func<Task>)AsyncTaskOp); 

     // Debugger stops on "Wait()" with "AggregateException" 
     Task.Run(() => AsyncTaskOp().Wait()); 

     // Throws "Exceptions was unhandled by user code" on "await" 
     Task.Run(() => AsyncVoidOp()); 

     Thread.Sleep(2000); 
    } 

    static void SyncOp() 
    { 
     throw new Exception("Exception in sync method"); 
    } 

    async static void AsyncVoidOp() 
    { 
     await AsyncTaskOp(); 
    } 

    async static Task AsyncTaskOp() 
    { 
     await Task.Delay(300); 
     throw new Exception("Exception in async method"); 
    } 
} 

bin ich etwas fehlt? Wie kann ich den Debugger dazu bringen, die Exception in AsyncTaskOp() zu brechen/stoppen?

+0

Haben Sie das jemals lösen? –

+0

@RichardSzalay Nein, leider nicht. Ich glaube, ich habe mich daran gewöhnt, damit zu leben. –

Antwort

25

Wählen Sie im Menü DebugExceptions.... Überprüfen Sie im Dialogfeld Ausnahmen neben der Common Language Runtime Exceptions Zeile die Thrown Box.

+14

Ok, das wusste ich. Aber dann bricht der Debugger alle * Ausnahmen, nicht nur die unbehandelten, richtig? Es ist also nicht genau das, wonach ich suche. –

+3

@SebastianKrysmanski: Die Ausnahme wird behandelt, obwohl. Wenn Sie eine Async-Task-Methode verwenden, wird die Exception von der Async-Statusmaschine abgefangen und auf die zurückgegebene Task gesetzt. –

+10

In Visual Studio 2015 finden sich die Ausnahmeeinstellungen unter 'Debug' >>' Windows' >> 'Exception Settings' (Strg + Alt + E) –

-2

Ich habe den anonymen Delegierten in einen Versuch/Fang innerhalb der Task.Run(() => gewickelt.

Task.Run(() => 
{ 
    try 
    { 
      SyncOp()); 
    } 
    catch (Exception ex) 
    { 
      throw; // <--- Put your debugger break point here. 
        // You can also add the exception to a common collection of exceptions found inside the threads so you can weed through them for logging 
    } 

}); 
+2

Hilft nicht, denn dann würde der Debugger an der Stelle brechen, an der die Ausnahme aufgetreten ist ist * gefangen * - nicht wo es * geworfen * wird. –

3

Ich würde gerne hören, wenn jemand herausgefunden hat, wie man dieses Problem umgehen kann? Vielleicht eine Einstellung im neuesten Visual Studio ...?

Eine unangenehme, aber praktikable Lösung (in meinem Fall) war meine eigene benutzerdefinierte Exception zu werfen und dann Stephen Cleary Antwort ändern:

Unter dem Debug-Menü die Option Ausnahmen (können Sie diese Tastatur verwenden Tastenkombination Strg +Alt + E) ... im Dialog Ausnahmen, neben der Common Language Runtime Exceptions überprüfen Linie die Thrown Box.

spezifischere das heißt zu sein, fügen Sie Ihre benutzerdefinierte Ausnahme in der Liste, und dann seine „Geworfene“ ankreuzen.

Z. B:

async static Task AsyncTaskOp() 
{ 
    await Task.Delay(300); 
    throw new MyCustomException("Exception in async method"); 
} 
+2

Was passiert, wenn 'Task.Delay()' eine andere Ausnahme auslöst? –

+0

Thomas, ich habe gerade das Beispiel des Original-Posters erweitert. Geht man von der Logik ab, kann * alles * scheitern - was richtig ist, aber wir müssen im Kontext antworten, ... damit wir für immer im Kreis herumlaufen können ... Meine Antwort ist im Zusammenhang damit, dass der Debugger bei einem gewünschten Halt bleibt Zeigen Sie im Code, wo Sie dann anzeigen können, was die lokalen Variablenwerte sind und was möglicherweise die Ausnahme verursacht. Dies ist nicht leicht zu erreichen, wenn die Ausnahme außerhalb der Task (wie OP) geworfen wird, da es zu einem Albtraum für das Debugging werden kann. – Jimbob

Verwandte Themen