![]() Mailinglisten-Archive |
Sebastian Mendel wrote: > Roland H�der schrieb: >> Dann bist du wieder bei Status-Code und Co. angekommen, was durch die >> Exceptions ersetzt werden soll. > > Wer sagt das? > > Exception = Ausnahme/Sonderfall > > die sind daf�r da wenn wirklich etwas unerwartetes passiert, wenn aus > irgendeinem Grund irgendetwas fehlschl�gt was zur Zeit der Programmierung > nicht ber�cksichtigt wurde, und nun trotzdem dem Benutzer in einer > akzeptablen wei�e erkl�rt werden muss, alles andere sind keine *Ausnahmen* > und eh durch das Programm zu behandeln. > > Bei einer Exception gibt es n�mlich eigentlich keine Zust�nde zum > Unterscheiden, bzw, kein Zustand mit dem ich etwas anfangen k�nnte - denn > dann w�re es keine Exception (Ausnahme). Nein, das ist nicht ganz richtig. Exceptions mit Ausnahme zu �bersetzen ist zwar nicht ganz falsch, aber Ausnahme mit Fatal Error gleichzusetzen ist schon falsch. Eine Exception heisst prinzipiell erstmal nur, dass etwas nicht so gelaufen ist, wie geplant. Um das ganze mal an einer Situation des echten Lebens zu illustrierten (die Beschreibung habe ich so �hnlich vor einigen Jahren selber mal gelesen... Fand ich sehr treffend): Dein Programm soll einem Kunde einen Kaffee servieren. Dazu hast du 3 Exceptions: TemperatureException extends Exception TooColdException extends TemperatureException TooHotException extends TemperatureException Hier k�nnen jetzt alle 3 Fehler auftreten: $bedienung->serveCoffee($costumer); Das ist garantiert keine Situation um sich jetzt heulend in die Ecke zu setzen und das ganze Problem als Designfehler zu deklarieren. Stattdessen kann man das Problem l�sen: try { $bedienung->serveCoffee($costumer); } catch(TemperatureException) { $bedienung->recollectCoffee(); $bedienung->complainTo($kitchenStaff); } oder, wenn das Unternehmen was kleiner ist: try { $bedienung->serveCoffee($costumer); } catch(TooColdException) { $bedienung->heatUpCoffee(); } catch(TooHotException) { $bedienung->addEiswuerfelToCoffee(); } ob das mit den Eisw�rfeln jetzt 'ne gute Idee ist, sei mal dahin gestellt, aber es sollte doch klar werden, wie man mit dem Problem umgehen kann und das Exceptions keinesfalls ein FatalError darstellen. Fr�he hat man das dann so gemacht, dass man einen Errorcode zur�ckgibt und dann in irgendwelchen Konstanten irgendwo steht, was das denn heisst. Das Exceptionsmodell hat jedoch den Vorteil, dass die Exceptions hoch blubbern, bis sie abgefangen werden. Die Fehlermeldung muss dadurch nicht zwangsweise direkt mit dem Funktionsaufruf in einem kommen. Das macht die Sache nicht nur wesentlich �bersichtlicher, sondern erzwingt auch, dass jeder Fehler, der auftritt behandelt wird. Schlimmsten falls l�uft die Exception bis zum Default Exceptionhandler durch, der dann normalerweise einfach den Stacktrace ausgibt und somit zumindest f�r den Programmierer schnell und hilfreich �ber den Fehler informiert. Bei dem Errorcodesystem w�re es hier nur zu "unexpected behaviour", gekommen und das Debugging h�tte ohne Anhaltspunkte viel Spa� gemacht. > > Exceptions sind nicht dazu um das misslingen einer Funktion, oder etwas > ung�ltiges o. �. zu melden. Doch, sind sie sehr wohl. Wenn es komplett den Bach runtergeht, verwendest du keine Exception, sondern gleich exit; Yannik
php::bar PHP Wiki - Listenarchive