nicht angemeldet
echo $begrüßung;
In meinen Verwendungszweck gibt es ansich keine Ausnahmesituation, vor jeder Aktion prüfe nach, ob die Aktion erfolgreich wird oder nicht (ein file_exists() vor einem file read z.b.).
Dein Programm ist Hellseher?
Zwar kann zwischen dem prüfen und dem lesen der Datei, die Datei verschwinden, jedoch müßte ich trotzdem manuell die Exception werfen (throw new Ex..), was bedeuetet, das ich *zweimal* ansich die gleiche Aktion überprüfe.
Einmal davor, und einmal die Aktion selber.
Du wirst nicht drumrum kommen, den Erfolg deiner Aktion zu prüfen. Du kannst beispielsweise nicht testen, ob ein DBMS eine Verbindung mit dir akzeptiert, wenn du diese Verbindung nicht aufbaust. Die Prüfung, ob das DBMS zur Verfügung steht ist nun bereits ein Hinterher. Wenn das DBMS beim Abfragen die Grätsche macht, dann ist das auch wieder ein Hinterher und kein Vorabprüfen. Wenn es keine gewichtigen Gründe für eine Vorabprüfung gibt, tät ich die mir sparen, und nur eine Erfolgsprüfung vornehmen.
Ich habe mir bereits folgendes überlegt:
In einem rießen großen Array, steht von jeder Klasse und jeder Methode, alle Verfügbaren Fehlermeldungen:
Schau dir lieber an, wie andere ihre Klassensammlung organisieren. Beispielsweise das Zend Framework. Die diversen Funktionalitäten sind in Paketen und teilweise Unterpaketen gegliedert. In diesen gibt es jeweils eigene Exceptions-Klassen, die die anderen Klassen dieser Pakete werfen können. Zu jeder Methode ist dokumentiert, welche Exception geworfen wird, so dass der Aufrufer sehen kann, was eventuell auf ihn zukommt.
Sollte nun irgendwo in einer Methode ein Fehler auftreten, gebe ich z.b. die ID 50 zurück:
return 50;
Bleibt die Frage, wie der Fehlerzustand von einer erfolgreichen Unternehmung zu unterscheiden ist. Außerdem ist jeder Rückgabewert einzeln zu prüfen. In einem try-Block kann man hinterenanderweg das notieren, was normalerweise passieren soll. Und im catch-Teil sammelt man die Fehlerbehandlung.
So weiß ich nun anhand des error-arrays + rückgabewert *irgendeiner methode* genau, woher der Fehler kommt und was das genau für ein Fehler ist.
Genau dies können Exceptions leisten. Sie haben diverse Standard-Eigenschaften, wie Errorcode und Meldungstext und können um beliebige Eigenschaften erweitert werden.
Jedoch leitet darunter stark die Modularität, ich bin immer abhängig von diesen Error-Codes, und besonders sauber scheint mir das auch nicht zu sein.
Frag einfach die Exception, was sie für ein Problem zu berichten hat, dann musst du dir keine Gedanken machen, wo du zum Code die passende Meldung herbekommst.
Am besten probierst du beide Ansätze aus und lernst dabei ihre Eigenschaften kennen und kannst sie als Vor- oder Nachteil einsortieren. Das mit dem Array ist so ähnlich in PEAR implementiert. Das wurde unter PHP4 erfunden, als es noch keine Exceptions gab. Im Fehlerfall wird immer ein PEAR_Error-Objekt statt des eigentlichen Wertes zurückgegeben. Das muss man ständig prüfen, denn ein PEAR_Error-Objekt hat nicht die Eigenschaften, die man normalerweise von seinem Rückgabewert erwartet. Das Zend Framwork hingegen setzt auf PHP5 auf und kann damit alle modernen OOP-Möglichkeiten nutzen, wie eben auch Exceptions.
echo "$verabschiedung $name";