Hallo,
meine persönlich Ansicht zu dem Thema (man kann sie teilen, muss es aber nicht):
Exceptions benutze ich grundsätzlich nicht als Rückgabewert. Nie!!!
Eine
Exception weist mich immer auf einen Fehler hin, bei dem ich "zu blöd" war, ihn durch eine vernünftige Programmierung abzufangen.
Eine
Exception ist immer eine Ausnahmesituation, in der versucht wird zu retten, was noch zu retten ist.
Sie dient niemals zur Steuerung irgendwelcher Programmabläufe.
Kann mich an ein Programm erinnern, dass ich von einem anderen Entwickler übernehmen musste. Er steuerte den Programmablauf durch Exceptions. Bei ihm gab es sowas wie EGoodException und EBadException (die hießen wirklich so und waren von EException abgeleitet). Und dann gab es noch etliche "Zwischendinger", die für mehr oder weniger gute oder schlechte Situationen genutzt wurden. Für mich persönlich läuft das unter "sehr schlechtem Programmierstil".
In dem besagten Programm war es extrem schwierig herauszubekommen, in welchem Programmteil es nach den diversen Exceptions nun weiterging bzw. was zur Fehlerbehandlung diente.
Es erinnert mich an andere Programme, die ich mal mitpflegen durfte (Basic bzw. PL/1). Dort wurde der Programmablauf nie in der Form
Delphi-Quellcode:
if x = y then begin
...
end;
gesteuert, sondern immer in der Form
Delphi-Quellcode:
if not (x = y) then GoTo Pxyz;
...
Hier dann die Logik für die Bedingung x = y
...
Goto Pxyz;
wobei xyz eine nummerischer Wert von 000 bis 999 sein konnte.
Extrem schwer, sich dort einzulesen und zurechtzufinden.
Funktionen oder Prozeduren wurden dort nicht genutzt, in Basic eventuell mal ein GoSub, aus dem aber durchaus per GoTo irgendwo in den Quelltext zurückgesprungen wurde, aus dem das GoSub aufgerufen wurde oder per GoTo irgendwo in so ein Sub mitten "hineinaberneineberneinabernein" und dann irgendwie mit GoTo wieder raus, da der "normal" Rückweg hinaus ja dann nicht funktioniert.
Mit dieser Methode und "Steuerung per
Exception" kann man wunderbaren Spagetticode erstellen, dessen Unpflegbarkeit quasi mit der Erstellung schon sichergestellt ist.
Für meine Begriffe ist dieses Vorgehen hochgradig unprofessionell. Habe bisher keine Software kennengelernt, die dauerhaft mit derartigen Konstrukten wartbar und weitereinwickelbar war.
Exception bedeutet meines Wissens
Ausnahme und nicht
Regel.
Exceptions dienen zur Ausnahmebehandlung (in der Regel ist dies die Fehlerbehandlung) und nicht zur regulären Programmsteuerung.
http://de.wikipedia.org/wiki/Ausnahmebehandlung
Was hathor beschreibt ist keine "Funktionssteuerung" per
Exception statt Rückgabewert, sondern eine Fehlerbehandlung. Im Fehlerfalle wird eine alternative Ausgabe gemacht. Die Funktion selbst behandelt die Fehler (hier fehlende Inhalte). Bei einer Fehlerbehandlung "per
Exception" müsste hier für jeden der möglichen Fehler eine spezielle
Exception existieren und natürlich auch für jede der daraus möglichen Kombinationen, da diese Funktion ja offensichtlich bei allen Fehlern schon selbst etwas macht bzw. die Fehler bei einer Exceptionsteuerung sammeln müsste, um sie dann gemeinsam weiterzugeben. Jeder einzelne Fehler kann ja nicht mit einer eigenen
Exception zurückgegeben werden, ohne den Programmablauf nach dem ersten Fehler zu unterbrechen. In dem Falle wäre eine Exceptionsteuerung mit einem nicht unerheblichen Programmieraufwand und einem nicht unerheblichen "Unübersichtlichkeitsfaktor" verbunden. Viel Vergnügen beim Implementieren.
Funktionen können bei korrekter Verarbeitung z. B. True und im Fehlerfalle False zurückgeben. Der Rest kann durchaus per VAR-Parameter zurückgegeben werden. Als Rückgabewert und/oder VAR-Parameter sind aber durchaus auch Records oder Klassen mit entsprechenden Attributen möglich. Hier geht (bei durchdachter Planung) deutlich mehr als ein "geht" oder "gehtnicht" (True / False).
Phoenix hat mit seiner Aussage absolut recht.