Tag 4

Vielleicht noch:

Robust Programmieren

Vielleicht zu fortgeschritten.... Siehe auch unser alter Vortrag zu Exceptions

Idee von Robuster Programmierung

wie kann man mit fehlern umgehen
- fehler(un)freundliche systeme (Flugzeug, Auto)
- bandbreite der fehler von lethal bis nervig, bis "man kann daraus etwas lernen" (feedback?)
- Folgekosten abschätzen
was will man eigentlich:
- etwas für die Benutzer tun
- diese in die Lage versetzen Selbst etwas zu tun
- Das ist eine Grundsätzliche Frage die man sich bei Software (und in der tat überall) stellen muss. Gleichzeitig ist das auch das Ziel einer persönlichen Weiterentwicklung, die sich eben auch (tja) in der Software die man schreibt wiederspiegelt.

Problemraum

Welche Fehler behandelt man?
welche gibt man an Benutzer weiter?
wie macht man das? (Schöne Dialogtexte, Gute Klare Fehlermeldungen)
- Apple HIG schreibt: "Provide useful error messages to users when something does go wrong. An error message should clearly convey what happened, why it happened, and the options for proceeding. Offer a workaround if one is available and do whatever you can to prevent the user from losing any data. See "Alerts" for more information on how to provide useful error messages." Siehe auch: Writing good Alert messages
  - In fast allen nichttrivialen fällen, kann man den Fehler nicht selber behandeln, sondern nur dem Benutzer die Information geben sie zu beheben. (ex. "FileNotFoundException" -> "Bitte legen sie den externen Datenträger "Blub" ein, auf dem sich die Datei "Bla" befindet") Aufwendiger - ja, aber notwendig!

Wo treten Fehler auf:

Benutzereingaben die anders sind als Vorhergedacht
Code, der mit externen Systemen (Netzwerk, Dateisystem, Geräte, Messfühler, Benutzer) kommuniziert
Oder Code der Fehler / Bugs enthält
- Nicht oder falsch verstandene eingabewerte für Methoden
- dynamischer OO-Code, bei dem der Compiler nicht mehr alles prüfen kann