Ich würde empfehlen auf einen Fehler immer mit einer
Exception zu reagieren.
Auf keinen Fall sollte man mit direkten Fehlermeldungen reagieren,
weil man dann unter anderem keinen Stacktrace erzeugen kann.
Delphi-Quellcode:
if telefonnr = '' then
begin
// Falsch
ShowMessage('keine Telefonnummer eingegeben');
exit;
end;
if telefonnr = '' then
// Richtig
raise EPlausiCheck.Create('Telefonnummer fehlt');
Wenn eine Funktion nicht leisten kann was ihr Name verspricht, dann muss eine
Exception ausgelöst werden.
Eine Funktion namens SaveStringToFile() sollte entweder den String in dem File speichern oder eine
Exception auslösen.
Auf einen Returncode (False=Fehler, True=alles ok) zu vertrauen wäre schlecht, denn wie leicht kann es passieren, dass man eine Funktion aufruft ohne das Ergebnis zu prüfen.
Siehe auch:
http://de.wikipedia.org/wiki/Fail-Fast
Zitat:
Some people recommend making
your software robust by working
around problems automatically.
This results in the software “failing slowly.”
The program continues working right after an
error but fails in strange ways later on.
A system that fails fast does exactly the opposite:
when a problem occurs, it fails immediately
and visibly. Failing fast is a nonintuitive
technique: “failing immediately and visibly”
sounds like it would make your software more
fragile, but it actually makes it more robust.
Bugs are easier to find and fix, so fewer go into
production.