Wolfgang Ziegler Selbstständig

Neben .NET 4.0 und 4.5 unterstützt Polly mittlerweile sogar .NET Standard 1.1 und steht somit auch für plattformübergreifende Projekte mit .NET Core zur Verfügung. Es handelt sich also ganz offensichtlich um ein sehr ausgereiftes Softwareprojekt, in das schon viel Know-how und praktische Erfahrung gewandert sind.

Fehlerbehandlung und stabiler Wiederaufsatz sind die Achillesfersen so mancher Softwareprojekte. Es kann sehr frustrierend sein, wenn vielleicht das Netzwerk kurz aussetzt oder der Speicherplatz auf der Festplatte zur Neige geht. Professionelle Software zeichnet sich dadurch aus, dass sie auch solche Szenarien vorsieht und korrekt behandelt. Noch einfacher geht das allerdings, wenn man hierfür auf ein bestehendes Framework zurückgreifen kann.

Saubere Fehlerbehandlung bzw. ihr Nichtvorhandensein ist ein Problem, mit dem wohl jeder Softwareentwickler schon in irgendeiner Form zu tun hatte. Sei es als Verursacher eines solchen Problems, wenn ein vermeintlich triviales Codefragment plötzlich doch eine Ausnahme verursacht, oder als Betroffener, wenn Code von Kollegen oder Vorgängern mit einem Mal die Stabilität der Anwendung beeinträchtigt. Selbstverständlich sollten wir es allesamt besser wissen, werden ab der ersten Stunde Programmierunterricht darauf gedrillt und gehen mit besten Absichten in jedes Projekt – und dennoch schleichen sich immer wieder Fehler in Anwendungen ein, die darauf zurückzuführen sind, dass man als Entwickler viel zu oft nur den „Happy Case“ durchdenkt und testet und viel zu selten die Ausnahmefälle. Warum das so ist, lässt sich möglicherweise anhand eines trivialen Beispiels plausibel und nachvollziehbar erklären (wenn auch nicht unbedingt entschuldigen). Stellen wir uns eine hypothetische Anwendung vor, die von Zeit zu Zeit oder auch ereignisgesteuert bestimmte Daten im Dateisystem ablegt, um auf diese Weise dem Benutzer zum Beispiel manuelles Speichern abzunehmen oder Wiederherstellungspunkte zu gewährleisten. Das Schreiben dieser Daten geschieht in einer Methode, die wir PersistApplicationData nennen:

private void PersistApplicationData()

Da diese Methode Zugriffe auf das Dateisystem vornimmt, kann das natürlich in gewissen Fällen zu Ausnahmen führen. So könnte beispielsweise kein Speicherplatz mehr auf dem Datenträger vorhanden sein. Eine Datei könnte unerwarteterweise von einer anderen Anwendung gerade exklusiv verwendet werden (Indexierungsdienste und Virenscanner sind hier immer für Überraschungen gut). Oder möglicherweise hat unsere Anwendung die Schreibrechte auf das Verzeichnis aus irgendeinem Grund verloren. Kurzum: Das Dateisystem ist als externe, nicht vollständig kontrollierbare Abhängigkeit zu betrachten, und der Aufruf unserer Methode muss jedenfalls mit einem try-catch-Konstrukt geschützt werden. Jede Verwendung von try-catch zieht unmittelbar die Frage nach sich, welche Art(en) von Exception(s) man nun damit abfangen möchte. Wählt man hier die Basisklasse Exception, sind damit zwar alle Fälle abgedeckt, allerdings ist das meist viel zu generisch. Ausnahmen vom Typ NullReferenceException oder AccessViolationException deuten beispielsweise meist auf Fehler in der Anwendungslogik hin, die wir vermutlich rechtzeitig entdecken und nicht still und heimlich ignorieren wollen. Somit bietet sich doch eher eine spezifische Ausnahmebehandlung an. Nehmen wir für unseren Fall an, dass mit Ausnahmen vom Typ IOException und InvalidOperationException zu rechnen sein wird, was in zwei catch-Blöcken resultiert. Gänzlich ignorieren will man aufgetretene Fehler im Normalfall auch nicht, also erhält jeder der beiden catch-Blöcke zumindest eine Zeile Logging-Code, um Informationen zum Fehler zu protokollieren.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Windows Developer 7.18 - ".NET ohne Grenzen"

Alle Infos zum Heft
579844581Stabilere Anwendungen mit dem Framework Polly
X
- Gib Deinen Standort ein -
- or -