Zitat von
stahli:
Nach 1 Jahr tritt ein unerkannter Fehlerfall auf, der Kunde ruft an und beschwert sich über eine Fehlermeldung und fragt, ob seine Daten noch stimmen. Dann muss das Problem geklärt werden. Ob Person.Free noch durchlaufen wurde oder nicht, interessiert da nicht wirklich - nur welche Daten noch geändert und gespeichert wurden und wie sichergestellt werden kann, dass der Fehler nicht wieder auftritt.
Leider rufen aber nicht alle Kunden an oder erst, wenn sie durch wiederholen der zum Fehler führenden Funktion, quasi sichergestellt haben, dass da ein Fehler auftritt.
Und eine Beschwerde / Frage, ob de Daten noch sicher und in Ordnung sind, mag es ja geben, aber die Antwort muss immer sein:
Ja die Daten sind sicher, die Daten sind in Ordnung. Wenn man da als Entwickler nicht sicher ist, dass man
immer diese Antwort geben kann, hat man was falsch gemacht.
Ein Programm muss immer so geschrieben sein, dass auch bei einem schweren und unerwarteten Fehler, die Sicherheit der Daten garantiert ist. Auch dann noch, wenn der Anwender das Programm gegen alle Regeln der Vernunft weiter benutzt, neu startet und die zum Fehler führende Aktion wieder ausführt, das schlimmstenfalls mehrfach ...
Der größte Aufwand beim Programmieren ist nicht, richtigen und sauber funktionierenden Code zu schreiben und für eine korrekte Arbeit des Programmes zu sorgen, sondern sicherzustellen, dass bei allem davon abweichenden die Sicherheit und Korrektheit weiterhin garantiert ist.
Sprich: Die Fehlerbehandlung macht deutlich mehr Arbeit, als die eigentliche Progammlogik.
Und Schutzblöcke sind ein kleiner Teilbereich dessen.
@jaenicke
Jo, det isset.
Egal was in einem Programm an Fehlern passiert: Es läuft weiter und zwar ohne jegliche Einschränkung. Einen Fehler, der zu dem von stahli angesprochenen Szenario führt, dass es egal ist, ob man aufräumt oder nicht,
darf es in Software für den professionellen Einsatz nicht geben Punkt. Und mindestens ein Dutzend Ausrufezeichen.