Exceptions Verständnis/Nutzen Frage

[Hagbard-Celine]

Hallo zusammen,

ich arbeite mich gerade in Design-Pattern ein und bin jetzt auch noch mal auf das Thema Exceptions gestoßen was ich lange Zeit gemieden habe weil mir der Nutzen nicht ganz klar war.

Nun muss natürlich was dran sein wenn es anerkannter Maßen als guter Stil gilt Exceptionhandlung statt IF/ELSE Konstrukte zu nutzen.

Also der Aufbau mit Try/Catch Blöcken und dem Werfen von Exceptions habe ich verstanden und ist auch zu genüge im Internet dokumentiert. Auch das Exceptions wie der Name schon sagt nur im Ausnahmefall geworfen werden sollten ist auch klar und nicht etwa um true/false in normalen Bedingungen zu behandeln.

Jetzt aber geht es um den nutzen.

Nehmen wir mal ein einfaches Beispiel ein Query über eine Methode einer MySQL Klasse:

Fehlerbehandlung mit Exceptions

public function doQuery($query)
{
   try
   {
      $this->_result = mysql_query($query, $this->_connection);
      if(!$this->result)
      {
         throw new Exeption('Fehler im SQL-Query');    
      }
   }
   catch(Exception $e)
   {
      echo $e->getMessage();
      // Sonstige Fehlerbehandlung
   }    
} 

Fehlerbehandlung mit IF/ELSE

public function doQuery($query)
{
   $this->_result = mysql_query($query, $this->_connection);
   if(!$this->result)
   {
         echo('Fehler im SQL-Query');    
         // Sonstige Fehlerbehandlung
   }
} 

Wie man sieht ist die IF/ELSE Methode (noch) übersichtlicher und mit weniger Code verbunden. Wieso sollte man hier trotzdem zu Exception-Lösung greifen?

Oder würdet Ihr das nur bei komplexeren Methoden machen wo viele mögliche Fehlerbehandlungen via IF/ELSE Verzweigungen sehr unübersichtlich werden könnten? Weil der nächste Vorteil die Exception Klasse erweitern zu können um so auf jeden Fehler individuell reagieren zu können habe ich natürlich bei IF/ELSE genauso.

Für mich gibt sich deshalb bis jetzt nur der, bei vielen abzufangenden Fehlern, besser zu überblickende Code. Einen sonstigen richtigen Mehrwert sehe ich noch nicht.

Eine andere Frage die ich noch hätte wäre wo man dann den Try/Catch Block aufführt in der Klasse/Methode selber wie oben im Beispiel?

Oder im Programmcode den Aufruf der Methode in Try/Catch packen?
Dann müsste ich mich darauf verlassen das die Methode immer in einem Try/Catch Blöck steht da sonst die geworfene Exception nicht behandelt wird und zu einem Scriptabbruch führt.

Aber normal sollte jeder die Klasse benutzen können ohne genau zu wissen was genau im Code gemacht wird ... also könnte auch unbekannt sein ob eine Exception geworfen wird.


Würde mich um konstruktives Feedback sehr freuen
(Und ja ich habe Google und sonstige Suchen benutzt und mir sehr viele Beiträge zu diesem Thema angesehen)

Vielen Dank!

[TobiaZ]

Wie du schon richtig erkannt hast, kommen Exceptions nur in Ausnahmefällen zum tragen. In deinem Beispiel würde folglich eine MySQL-Query fehlschlagen.

Dieser Fall tritt eigentlich so gut wie nie ein, weil du ja die Werte vorher geprüft hast. Falls er nun doch eintritt, kannst du nicht mehr viel retten, höchstens Loggen. Das Ding ist fehlgeschlagen, also längst in den Brunnen gefallen, und das obwohl die Rahmenbedingungen von Seiten des Users korrekt sind.

In deinem Beispiel liefern Exceptions in der Tat keinen Vorteil. Aber geh mal davon aus, dass du die Fehlerbehandlung einem Exception Handler übergibst, dann sieht die Sache schon wieder ganz anders aus. Bei jeder fehlgeschlagenen Query wirfst du z.B. eine MySqlException. Somit brauchst du die nachfolgende Behandlung (Loggen des Fehlers, Informieren des Admins, Speichern der Degubinformationen, Neutrale Meldung an den User) nur noch einmalig zu implementieren. Und das mit all seinen Vorteilen.

[onemorenerd]

Dein erster Code-Abschnitt ist Käse. mysql_query() wirft keine Exceptions. Deswegen kann das try-catch weg. Übrig bleibt quasi der selbe Code wie in deinem zweiten Beispiel, nur dass eben kein echo erfolgt sondern throw.

Wenn du dir nun überlegst, wie der Fehler an der Stelle erkannt wird, wo deine Methode aufgerufen wurde, wirst du den Vorteil von Exceptions sicherlich einsehen - der Aufrufer würde vom echo und damit vom Auftreten des Fehlers gar nichts mitbekommen. Das schlägt direkt bis zum Client durch und der kann mit dieser Fehlermeldung auf deiner Webseite überhaupt nichts anfangen. ;-)
Natürlich kannst du statt echo auch return false machen. Aber dann muss jedem Aufruf von doQuery() ein Test des Rückgabewerts folgen.
Bei tiefen Callstacks ist man da mit Exceptions besser beraten. Die kann man auch einfach mal nicht fangen und es einer höheren Schicht überlassen oder man kann sie fangen und erneut werfen oder konvertieren oder oder oder.

[unset]

Genau dazu habe ich vor über einem Jahr schon was geschrieben: Re: Wann verwende ich Exceptions // der php hacker ? ein php blog

[Hagbard-Celine]

Erstmal Danke für die vielen schellen, guten Antworten.

Dein erster Code-Abschnitt ist Käse. mysql_query() wirft keine Exceptions. Deswegen kann das try-catch weg. Übrig bleibt quasi der selbe Code wie in deinem zweiten Beispiel, nur dass eben kein echo erfolgt sondern throw.

Wenn du dir nun überlegst, wie der Fehler an der Stelle erkannt wird, wo deine Methode aufgerufen wurde, wirst du den Vorteil von Exceptions sicherlich einsehen - der Aufrufer würde vom echo und damit vom Auftreten des Fehlers gar nichts mitbekommen. Das schlägt direkt bis zum Client durch und der kann mit dieser Fehlermeldung auf deiner Webseite überhaupt nichts anfangen. ;-)
Natürlich kannst du statt echo auch return false machen. Aber dann muss jedem Aufruf von doQuery() ein Test des Rückgabewerts folgen.
Bei tiefen Callstacks ist man da mit Exceptions besser beraten. Die kann man auch einfach mal nicht fangen und es einer höheren Schicht überlassen oder man kann sie fangen und erneut werfen oder konvertieren oder oder oder.

OK das mit dem überflüssigen Try/Catch Block habe ich verstanden.

Das mit dem Echo war nur ein Beispiel und sollte nicht die tatsächliche Fehlerbehandlung darstellen, ich wollte das Beispiel nur möglichst kompakt halten.

Aber statt einem Try/Catch beim Aufrufen hätte ich, wie Du schon richtig sagst, auch false benutzen können. Ob ich jetzt jedes mal auf den Rückgabewert teste oder jedesmal ein Try/Catch Block erzeuge dürfte kaum einen unterschied machen (vom Aufwand).

[h3ll]

Aber statt einem Try/Catch beim Aufrufen hätte ich, wie Du schon richtig sagst, auch false benutzen können. Ob ich jetzt jedes mal auf den Rückgabewert teste oder jedesmal ein Try/Catch Block erzeuge dürfte kaum einen unterschied machen (vom Aufwand).

Eine Funktion sollte nur einen Datentyp liefern. Also wenn du einen Boolean-Wert erwartest und TRUE oder FALSE lieferst, ist das in Ordnung. Wenn du allerdings einen String oder ein Array erwartest, aber plötzlich FALSE daher kommt, ist das nicht wirklich sauber.

[fireweasel]

Hallo zusammen,

ich arbeite mich gerade in Design-Pattern ein und bin jetzt auch noch mal auf das Thema Exceptions gestoßen was ich lange Zeit gemieden habe weil mir der Nutzen nicht ganz klar war.

Exceptions und Design-Patterns existieren unabhängig voneinander.

Nun muss natürlich was dran sein wenn es anerkannter Maßen als guter Stil gilt Exceptionhandlung statt IF/ELSE Konstrukte zu nutzen.

Wer sagt, dass es als guter Stil gilt?

Also der Aufbau mit Try/Catch Blöcken und dem Werfen von Exceptions habe ich verstanden ...

Offensichtlich noch nicht, wie dein Code-Beispiel zeigt. Sagen wir mal so: Dein Verständnis von Exceptions erscheint mir in etwa so gut wie meine Kenntnisse in Schach. Ich weiß, wie man die Figuren rückt ... ;-)

Wozu dienen Exceptions?

1.) In so komisch designeten Sprachen wie PHP sind sie eine Krücke, mit der eine Funktion zusätzliche Rückgabewerte an ihren Aufrufer senden kann. Für PHP ist das ganz wichtig, denn hier können bspw. Konstruktur-Funktionen überhaupt nichts zurückgeben. Wenn man jetzt ein Objekt "instanziiert", hat man keine Möglichkeit, einen Fehler zu melden, außer man benutzt Exceptions. Dies wird zwar gemeinhin als schlechter Stil betrachtet, aber wir haben ja nichts besseres ... ;-)

2.) Der Quellcode lässt sich einfacher gestalten, weil der Ablauf im Normalfall einfacher ersichtlich ist. Ein Beispiel: Wir schreiben Text in ein Logfile ...

function write_to_log($path, $log_txt) {
    $file = file_object::open($path, 'a');
    $file->write($log_txt);
    $file->close();
    return TRUE;
} 

In der Praxis könnte das Probleme bereiten, weil Dateien nicht immer vorhanden sind, nicht an jedem Pfad-Ende eine Datei sitzt (es gibt auch Verzeichnisse), man nicht immer Schreibrechte besitzt und Festplattenspeicher endlich ist. All diese Eventualitäten sollte man abfangen. Das geht mit "IFs":

function write_to_log($path, $log_txt) {
    if (!is_object($file = file_object::open($path, 'a')) {
        return FALSE;
    }
    if (
        is_int($bytes_written = $file->write($log_txt)) &&
        $bytes_written === strlen($log_txt)
    ) {
        $file->close();
        return FALSE;
    }
    $file->close();
    return TRUE;
} 

Aber hier kann man den ursprünglichen Programmablauf nicht mehr so gut erkennen.

Mit Exceptions dagegen, bleibt fast alles beim alten, wenn man mal vom catch-Block absieht:

function write_to_log($path, $log_txt) {
    try {
        $file = file_object::open($path, 'a');
        $file->write($log_txt);
        $succes = TRUE;
    }
    catch (file_object_exception $ex) {
        // handling $ex if needed
        $succes = FALSE;
    }

    $file->close();
    return $succes; 

Selbstverständlich müssen die aufgerufenen Funktionen (oder Objekt-Methoden) auch die richtigen Exceptions werfen. Auch deswegen ist dein Beispiel nicht besonders praxisnah. Es gibt aber diverse Datenbank-Extensions, mit denen man Exception-Handling schön üben kann (bsp. das übersichtliche SQLite3).

Oder würdet Ihr das nur bei komplexeren Methoden machen wo viele mögliche Fehlerbehandlungen via IF/ELSE Verzweigungen sehr unübersichtlich werden könnten?

In selbstgeschriebenen Funktionen verzichte ich nach Möglichkeit darauf Exceptions zu werfen.

Für mich gibt sich deshalb bis jetzt nur der, bei vielen abzufangenden Fehlern, besser zu überblickende Code. Einen sonstigen richtigen Mehrwert sehe ich noch nicht.

Exceptions sind in PHP die einzige Möglichkeit aus einem Objekt-Konstruktor heraus einen Fehler zu melden. Da gibts nichts mit IF-ELSE.

...

Dann müsste ich mich darauf verlassen das die Methode immer in einem Try/Catch Blöck steht da sonst die geworfene Exception nicht behandelt wird und zu einem Scriptabbruch führt.

Das ist das Prinzip dahinter: Fange alle Exceptions ab, die deine Kind-Funktionen werfen, wenn du sie behandeln kannst. Wenn nicht, reiche sie an deinen Aufrufer weiter. Das führt dann letzten Endes oft zu lustigen Trace-Back-Debugging-Sessions ... ;-)

Aber normal sollte jeder die Klasse benutzen können ohne genau zu wissen was genau im Code gemacht wird ... also könnte auch unbekannt sein ob eine Exception geworfen wird.

Das Werfen von Exceptions gehört zur Schnittstelle (Signatur, oder wie auch immer man das nennt) einer Funktion (wie bspw. die Rückgabewerte und die Aufruf-Parameter). Wer die Funktion nutzt, muss auch damit rechnen, das Exceptions geworfen werden. In vernünftig designeten Sprachen muss man dies auch angeben (bspw. mit dem Keyword "throws" in Java).

[Hagbard-Celine]

Hallo Fireweasel,

danke für deine ausführliche Erklärung.

[onemorenerd]

Das Schöne an Exceptions im Vergleich mit Rückgabewerten ist nicht nur die bereits erwähnte Typenstringenz, sondern dass Exceptions einen anderen Code Flow ermöglichen. Return false führt zurück zum caller und der muss darauf reagieren. Sonst knallts. Throw springt ebenfalls aus dem aktuellen Scope, aber wenn der übergeordnete kein catch implementiert, nibbelt die Exception weiter nach oben. Man muss also nicht überall Fehlerbehandlung einbauen und kann dabei sicher sein, das trotzdem kein Code ausgeführt wird, der mit dem Fehler nicht umgehen kann.

[Hagbard-Celine]

Hallo zusammen,

entschuldigt das ich den Thread wieder nach oben hole ich wollte aber keinen neuen erstellen weil sich meine neue Frage auch auf Exceptions bezieht.
Also ich habe mich jetzt noch weiter eingelesen und wollte für die verschiedenen Arten von Fehlern die meine Klasse werfen kann eigene Exceptions erstellen damit ich die Fehler besser individuell behandeln kann.

Nun ist dies ja recht einfach mit möglich:

class MyException extends Exception
{
/* CODE */
}

Meine Frage ist nun jedoch wohin würde man diesen Code packen?
In eine eigene myexception.php Datei und diese in der benötigen Klasse includieren? Oder packt man den Code einfach in die selbe Klassen-Datei in der Sie auch benötigt wird?

Oder ist das Fall abhängig?

Momentan würde ich wie folgt vorgehen:

1)
Eigene Exception wird in 2 Klassen gebraucht. Ich erstelle eine eigene PHP-Datei mit dem Code der eigenen Exception und binde diese in beiden Klassen per require ein.

2)
Eigene Exception wird nur in einer Klasse benötigt. Ich schreibe den Code der eigenen Exception in die PHP-Datei der Klasse mit rein.


Ist das so korrekt oder was ist dort Best Practise/empfohlen?


Besten Dank

[h3ll]

Üblicherweise ist eine Klasse eine Datei.

[onemorenerd]

Autoload statt require.

[TobiaZ]

entschuldigt das ich den Thread wieder nach oben hole ich wollte aber keinen neuen erstellen weil sich meine neue Frage auch auf Exceptions bezieht.

Dafür ist er ja da!

Momentan würde ich wie folgt vorgehen:
1) Eigene Exception wird in 2 Klassen gebraucht. Ich erstelle eine eigene PHP-Datei mit dem Code der eigenen Exception und binde diese in beiden Klassen per require ein.
2) Eigene Exception wird nur in einer Klasse benötigt. Ich schreibe den Code der eigenen Exception in die PHP-Datei der Klasse mit rein.

Du kannst ja vorher nie wissen, was vielleicht noch kommt.

Daher: Je Klasse eine Datei. Und Autoloading verwenden.

[Hagbard-Celine]

Hi Leute,

wow das ging mal fix.
Vielen Dank für die vielen Antworten.

Dann werde ich es mit einer eigenen Datei + Autoloading machen.