Ich habe diesen einfachen Code:
%Vor%Die Ausgabe:
%Vor%msdn:
TaskContinuationOptions.NotOnFaulted
Gibt an, dass der Fortsetzungs-Task nicht geplant werden soll, wenn sein Vorgeschichte warf eine unbehandelte Ausnahme. Diese Option ist nicht gültig für Multi-Task-Fortsetzungen.
ok.
Und es ist in Ordnung - wenn diese Zeile nicht angezeigt wird, wird die Exception ausgelöst.
Fragen:
Bekomme ich die Ausnahme AggregateException
, weil ich die Eigenschaft Exception
nicht überprüft habe?
Muss ich immer prüfen, ob die Antezedenz eine Ausnahme auslöst (in jeder Zeile?)? ( Ich kann nicht jede Zeile prüfen! Es macht keinen Sinn und ist sehr ärgerlich )
War der try catch
Block nicht die Ausnahme? (Ich dachte, dass alle Ausnahmen bis zur Warte-Methode platzen .... so?)
Bekomme ich die
AggregateException
-Ausnahme, weil ich nicht inspiziert habe die EigenschaftException
?
Nein, Sie erhalten eine Ausnahme, weil die Aufgabe g
nach TPL storniert wird (weil, wie msdn angegeben wurde, diese Aufgabe nicht geplant wird, wenn eine Aufgabe eine Ausnahme auslöst).
Wir haben 3 Aufgaben hier:
Das Problem ist, dass Sie TPL bitten, die 3D-Aufgabe nur dann zu starten, wenn die zweite Aufgabe erfolgreich abgeschlossen wird . Das heißt, wenn diese Bedingung nicht erfüllt wird, wird TPL Ihre neu erstellte Aufgabe vollständig abbrechen.
Sie haben eine unbeobachtete Aufgabenausnahme erhalten, weil Sie eine temporäre Aufgabe (Aufgabe 2 in meiner Liste) haben, die Sie nie beobachten. Und weil Sie niemals einen fehlerhaften Zustand beobachten, wird er den Finalizer einwerfen, um Ihnen davon zu erzählen.
Sie können dies überprüfen, indem Sie den Status der Aufgabe im Catch-Block drucken:
%Vor%Muss ich immer prüfen, ob die Antezedenzien eine Ausnahme (in jedem Fall) werfen Linie ? ) (Ich kann nicht jede Zeile überprüfen! Es macht keinen Sinn und sehr nervig)
Ja, Sie sollten die Ausnahme für vorhergehende Aufgaben beobachten, um dieses Problem zu vermeiden:
%Vor%Und dann benutze es wie folgt:
%Vor%UPDATE: Lösung zum letzten Punkt hinzugefügt
War der Versuch, den Catch-Block zu verwenden, nicht die Ausnahme zu schlucken? ( ICH dachte, dass alle Ausnahmen bis zur Warte-Methode platzen .... so? )
Wir haben in unserem Projekt eine Erweiterungsmethode (genannt TransformWith
), die dieses spezielle Problem lösen und folgende Vorteile erzielen kann:
TaskUnobservedException
abstürzen
Hier die Verwendung
%Vor%Und hier ist eine Erweiterungsmethode:
%Vor%Bekomme ich die Ausnahme "AggregateException", weil ich sie nicht überprüft habe die Ausnahmeeigenschaft?
Tasks werfen immer AggregateException: Ссылка
Sie können die ursprüngliche Ausnahme mit folgendem Befehl erhalten:
%Vor%Muss ich immer prüfen, ob die Antezedenzien eine Ausnahme (in jedem Fall) werfen Linie ? ) (Ich kann nicht jede Zeile überprüfen! Es macht keinen Sinn und sehr nervig)
Ja, es ist nervig, Sie sollten zwei Fortsetzungen für jede Aufgabe erstellen, um Ausnahmen zu überprüfen: eine, die prüft, ob es eine Ausnahme gab, um sie zu behandeln, und eine weitere, um die Operation fortzusetzen, wenn es keine Ausnahme gab. siehe TaskContinuationOptions.OnlyOnFaulted
und %Code%.
Sie sollten sogar eine dritte Fortsetzung erstellen, um bei Bedarf mit der Löschung fertig zu werden.
War der Versuch, den Catch-Block zu verwenden, nicht die Ausnahme zu schlucken? ( ICH dachte, dass alle Ausnahmen bis zur Warte-Methode platzen .... so? )
TaskContinuationOptions.OnlyOnRanToCompletion
in der Taskfortsetzung verwenden, um zu prüfen, ob eine Ausnahme aufgetreten ist. Sie können Aufgabenausnahmen auf Ebene des Aufrufers nur mit dem async Schlüsselwort erhalten, das in .net nicht verfügbar ist 4
Tags und Links .net c# multithreading task-parallel-library .net-4.0