Ich frage mich, warum MailboxProcessor
's Standardstrategie der Behandlung von Ausnahmen ist nur still ignorieren sie. Zum Beispiel:MailboxProcessor und Ausnahmen
let counter =
MailboxProcessor.Start(fun inbox ->
let rec loop() =
async { printfn "waiting for data..."
let! data = inbox.Receive()
failwith "fail" // simulate throwing of an exception
printfn "Got: %d" data
return! loop()
}
loop())
()
counter.Post(42)
counter.Post(43)
counter.Post(44)
Async.Sleep 1000 |> Async.RunSynchronously
und nichts passiert. Es gibt keinen fatalen Stopp der Programmausführung, oder es erscheint ein Meldungsfeld mit "Eine unbehandelte Ausnahme". Nichts.
Diese Situation wird schlimmer, wenn jemand PostAndReply
Methode verwendet: ein garantierter Deadlock als Ergebnis.
Gründe für ein solches Verhalten?
Ja, es kann natürlich implementiert werden. Ich verstehe nicht, warum * Standard * Verhalten so sprachlos ist. Es kann eine Exception erneut ausgeben, wenn sich beispielsweise keine Handler in 'MailboxProcessor.add_Error' befinden. Es ist schwierig, Async/Multithread-Code zu debuggen. Warum sollten wir diese Aufgabe noch schwerer machen? – qehgt
Sie können argumentieren, dass es besser wäre, den Prozess (unbehandelte Ausnahme) herunterzufahren, wenn keine Handler angehängt wurden. Ich erinnere mich nicht an die Gründe. – Brian
Ein Problem beim erneuten Auslösen von Ausnahmen besteht darin, dass Sie den Stack-Trace verlieren - zum Beispiel 'async {failwith" bad "}' gibt einen Stack-Trace, der tief in die F # -Bibliotheken zeigt, was lästiges Debugging sein kann Erneutes Auslösen von Ausnahmen in einem anderen Thread –