phpbar.de logo

Mailinglisten-Archive

[php] try catch

[php] try catch

Yannik Hampe yannik at cipher-code.de
Mit Apr 16 16:40:11 CEST 2008


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