Hallo,
ich habe eine Best Practice Frage zu Exception Handling. Ich habe zwei Funktionen System.IO.CreateDirectory und System.IO.Compression.ExtractToFile. Diese Funktionen können ja viele Exceptions werfen. Was wäre hier Best Practice? Ich würde nur die Exceptions catchen, die in meinem Fall auftreten können und am Ende würde ich die allgemeinste Exception Klasse catchen. Was meint Ihr?

Zitat von degri2006

Ich würde nur die Exceptions catchen, die in meinem Fall auftreten können

Nein, es kann ja alles mögliche passieren. Was macht den der Prozess? Jemand will was speichern?. Dann könntest du doch einfach dem Benutzer die Fehlemeldung anzeigen.

Hallo degri2006,

Zitat

Ich würde nur die Exceptions catchen

fange nur die Exception die auch behandelt werden können bzw. dessen Behandlung sinnvoll ist.
"Behandeln" ist z.B. Loggen, dem Benutzer zeigen dass etwas nicht passt um es erneut zu versuchen, usw.

Irgendwo in der Anwendung (du schreibst nicht ob es eine Client- / Server-Anwendung ist) sollte allerdings ein "catch all" durchgeführt werden, damit es keinen unbehandelten Fehler (unhandled exception) gibt, welche den Prozess terminieren würde.
(Achte auch bei Threads / Tasks darauf dass die nicht unbehandelt bleiben).



mfG Gü

Es handelt sich um ein Blazor Projekt(serverseitig) unter Linux. Es werden regelmäßig zip-Dateien in einem Verzeichnis abgelegt(/quellverzeichnis/md5einerbestimmtendateiimzip/a1.zip.). Das Verzeichnis hat nur Leserechte. Die Zip-Datei hat immer eine bestimmte Datei(log/log.json), die ich zum Weiterverarbeiten brauche. Diese Datei entpacke einem Hintergrundthread in ein Verzeichnis(Verzeichnis muss erzeugt werden) auf dem ich Schreibrechte habe: /verzeichnismitschreibrechten/md5einerbestimmtendateiimzip/log.json. Thread checkt voher ob, die Datei existiert. Wenn ja, dann geht zur nächsten zip. Wenn er alle zips durch sind, dann geht er für 10 Minuten schlafen.

Dann schreib das bitte nächstes Mal dazu, denn hellsehen können wir nicht und wenn Du das zu einer Runtime wie Blazor wissen willst, dann ist das eine spezifische Frage und nicht allgemein.
Ich hab daher entsprechend den Titel um die Technologie erweitert.

Bitte erklär, was Du unter Exception Handling verstehst; denn so wie es sich liest meinst Du nicht Best Practices für Ausnahmen – .NET

Zitat

Thread checkt voher ob, die Datei existiert. Wenn ja, dann geht zur nächsten zip. Wenn er alle zips durch sind, dann geht er für 10 Minuten schlafen.

Auch wenn ich eine Processing Engine nicht direkt über Blazor machen würde: ein klassischer Fall für Datenfluss (Task Parallel Library)
Mit Dataflow lassen sich serielle Aufgaben sehr einfach umsetzen und skalieren.

Zitat

Ich würde nur die Exceptions catchen, die in meinem Fall auftreten können und am Ende würde ich die allgemeinste Exception Klasse catchen.

Ich sehe das wie gfoidl - Exceptions catchen nur, wenn notwendig oder Du sie wirklich behandeln kannst.
Also wenn das Programm/der Thread abstürzen würde, der Click-EventHandler vom Button zuende ist, etc. - dann darfst Du generell fangen und ggf. loggen oder eine Fehlermeldung anzeigen. Ansonsten ist ein Catch nur sinnvoll, wenn Du über das Catch einen alternativen Ablauf steuern kannst, der genauso zum gültigen Ergebnis führt.

Es gäbe aber noch einen Fall:
Du wirfst im Catch die Exception weiter (nur "throw;" nicht "throw ex;"), das erlaubt dir vorher z.B. den Zustand aufzuräumen.
Kein "throw ex;" deshalb, weil dabei der StackTrace verloren geht, das würde die Exception wie eine neue Exception behandeln und das willst Du nicht.


Exceptions fangen und eigene Exceptions werfen kann sinnvoll sein, ist aber mit Vorsicht zu genießen - und dann solltest Du das Original möglichst als InnerException beibehalten.
Das kann z.B. sinnvoll sein, wenn Du mehrere Implementierungen einer Schnittstelle hast, die je Implementierung auch die gleichen Exceptions werfen muss, damit der Aufrufer die unterschiedlichen Exception-Typen nicht beachten muss.

Mir ging es nur grundsätzlich darum wie Ihr das mit den Exception handhabt, wenn Ihr eine Funktion bentutz, die potentiell viele Exceptions werfen kann. Unabhängig von dem Framework/Technolgie, die eingesetzt wird.

Es ist eine Methode, keine Funktion. In C# sind Funktionen etwas anderes.

Wie man generell Exceptions behandelt steht im Docs-Link.
Alle weiteren Umsetzungen sind im Endeffekt anwendungspezifisch bzw. kommt es auf die Exception an.

Gibt Exceptions, die kann man automatisch lösen, versuchen automatisch zu lösen; gibt welche, da muss der User aktiv werden und es gibt welche, die man gar nicht behandeln kann.