edit
Error Handling Design
Massnahmen für Fehler-Vermdeidung
- Testing / Simulation
- Statische Analyse
- Architektur (-Review)
- Deliberate Programming
- Reviews
Defensive Programmierung
Systematische Fehlerprüfung
- Alle Werte von externen Quellen werden geprüft
- Ungültige Zustände werden behandelt
- Systematisch abfangen
- z.B. Default case bei
switch
- Ungültige Benutzer-Eingaben verhindern
- Prüfung von Funktions-Input
- Preconditions vor Ausführung prüfen
- Nachteile
- Kann u.U. nicht getestet werden
- Kostet etwas (mehr Programmieraufwand, mehr Laufzeit)
- Duplizierter Code
Fehler-Barrikaden
- Externe Eingaben sind zuerst "untrusted" und müssen durch eine Barrikade gehen, wo sie getestet werden
- Precondition muss so nicht bei jeder Methode geprüft werden, sondern nur einmal
- Implementation
- z.B. über eine Facade nur gültige Daten "rein lassen"
- Datacontracts, wenn z.B. eine Konfiguration eingelesen wird
- Public-Methods überprüfen Daten, private Methods gehen von gültigen Daten aus
Systematische Fehlerbehandlung
- Fehler erkennen und melden
- Hängt stark vom System ab, ein Auto z.B. kann bei Fehler nicht einfach weiter fahren
- Sicherheitskritische Systeme sollten bei einem Fehler in einen sicheren Zustand
- Nicht-sicherheitskritische Systeme sollten Fehler loggen und robust sein bei Fehler, dh. versuchen am Laufen zu halten
- Konservative Behandlung
- Fehlermeldung anzeigen
- Shutdown
- Optimistische Behandlung
- Neutrales Resultat
- Nächstmöglich plausibles Resultat wählen
- Warnung loggen
- lokale Behandlung
- Nur für erwarteten Fall, wenn Fall lokal abschliessend entscheidbar ist
- In java checked exceptions
- globale Behandlung
- Wenn nicht lokal behandelbar
- Fehler ist auf höherer Ebene relevant
- In Java unchecked (Runtime) Exceptions (z.B. NullPointerException), da es überall passieren könnte
- In Java kann ein global Error Handler definiert werden, der z.B. alle Exceptions loggt
- Fehlerbehandlung kann auch Fehler enthalten!
- Einfach halten
- ebenfalls testen
Assertions
- Logisch dassselbe wie
if.. else throw
- Kann von der Runtime an- oder abgeschaltet werden, z.B. für Debug-Umgebung
- Für produktive Fälle wie externe Quellen immer Exceptions verwenden!
- Assertions für Programmierfehler verwenden, die nie auftreten dürfen
- Sicher sein, dass sie immer wahr sind! Quasi als formale Kommentare
- z.B. wenn man bereits weiss, dass Preconditions erfüllt sind
- Kein Ausführbarer code, bzw. keine Seiteneffekte! Assertions werden nicht immer ausgeführt
- Für Tests assertions abschalten, wenn sie in der Produktion auch disabled sind