Martin Häcker/Java Kurs/Tag 3

<- Zurück zur Übersicht

LE 5: Strukturiertes Programmieren und Testen

Methodik

• Allgemein: Wie entwickelt man Programme Stück für Stück?
  • Wie zerlegt man ein Problem in kleine Stücke
    • Top-Down vs. Bottom-Up <- letzteres empfiehlt sich für beginnende programmierer
  • Wie zeigt man das das kleine Stück das man schon hat funktioniert

• Java: Wie findet man effizient Fehler?
  • Greenspuns third law of programming: "Debugging is at least twice as hard as Programming. So, if you program as clever as you can, you are by definition too dumb do debug it."
    • Einfachheit bringt funktionierende Programme
    • Man hat eigentlich ein Kommunikationsproblem: Das was man will, muss man in Code hinschreiben - aber so exact das es sogar ein Computer ausführen kann. Gleichzeitig ist das eigentliche Ziel des Programms, das der Programmierer es lesen und verstehen kann. Für ihn (und andere) ist der code geschrieben!
    • Vorsicht vor
      • langen Funktionen
      • Namen die nicht den zweck einer Variablen zeigen
      • tiefen verschachtelungen
      • komplizierten if-/while-/for-Bedingungen
      • allem was man nicht auf den ersten Blick sieht
    • Beispiele für jede dieser Sachen (if-gotcha, lange funktion, blöde namen, komplizierte if-bedingung (klammerfehler), ...)
  • Hat viel mit erfahrung zu tun - man muss also schon jede menge Fehler finden um gut zu werden - aber es gibt auch techniken
  • Gefundene Fehler korrigieren
  • Debugging (mit Vorführung)
  • Testen: Selber Fehler finden (mit Vorführung)
  • Seperat testen (von main aus)

• Konkretes Vorgehen
  • Laufend kompilieren, nicht erst am Ende!
  • Laufend testen, nicht erst am Ende!
  • Wie man das macht
• Ausblick: Automatisierung
  • Welche änderungen im Arbeitsprozess das mit sich bringt

• Tools
  • Eclipse
  • CVS/SVN?

Übungsaufgaben

• Selber ein schlechtes Programm "fehlerbeseitigen lassen"
• schlechte Bezeichnungen durch bessere ersetzen lassen
• Debuggen mit Eclipse

LE 6: Robust Programmieren

Inhalt

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

Technisch

• Exceptions
  • ' try / catch
  • NICHT MACHEN: try {} catch (Throwable e) {}
• Rückgabewerte
• Wann ist was besser

Praxis: Wie verwendet man das

• Beispiel Fehlerbehandlung mit Rückgabewert (C?) (Apple hatte da ein Beispiel Living in an Exceptional World Interessant, aber irrelevant
• Beispiel Fehlerbehandlung mit Exceptions
• Vorsicht: Raymond Chen sagt dazu gerne cleaner, more elegant - and wrong!, Cleaner, more elegant and harder to recognize
• Exceptions sollen NICHT für flow controll verwendet werden
  • Beispiel

try {
      int sum = 0, i = 0;
      while (true) {
              sum += anArray[i++];
      }
} catch (IndexOutOfBoundsException expected) {}
// und weiter gehts....

Übungsaufgaben

<- Zurück zur Übersicht