PHP Exceptions

Lesetipps

1. Exceptions im Destruktor
2. Wann verwende ich Exceptions?
3. Leere try catch Blöcke

Ich habe mich ja schonmal daran versucht zu beschreiben, wann man Exceptions verwenden soll. Welche Exeptions aber wann geworfen werden sollen, möchte ich heute angehen. PHP liefert nämlich mit der SPL schon out-of-the-box ein paar Exception mit, die man sich ja mal anschauen kann.

Um ganz ehrlich zu sein, habe ich die meisten der Exceptions selbst noch nicht verwendet, aber die Chance ist größer es mal zu tun, wenn ich sie hier jetzt mal eine Runde beschreibe. Es ist einfach sinnvoll etwas standardisiertes zu verwenden, wenn es nun mal schon da ist. Und da ich eh meine eh Ableitungshierarchie nicht frei wählen kann, nehme ich im besten immer die am ehesten passende Exception.

• BadFunctionCallException
  Diese Exception wird geworfen, falls man einer Funktion nicht genügend Parameter übergibt oder falls der Parameter ein Callback auf eine undefinierte Funktion ist.
• BadMethodCallException
  Naja wenn die obere Ausnahme dazu da ist für Funktionen zu gelten, dann wird diese das gleiche wohl für Methoden gelten. An der Stelle finde ich es natürlich irgendwie doof, dass auch Methoden functions sind und es damit irgendwie konfus ist.
• DomainException
  Um ehrlich zu sein, habe ich keine Ahnung, was diese Exception soll. Die Doku sagt leider auch gar nichts. Ich kann einfach nur mal raten. Mein Tipp wäre, dass man diese Ausnahme dann verwendet, wenn man in seiner Domäne, also in seiner Applikation einen etwas aufzeigen will. Hmmm. Naja macht nicht so viel Sinn, oder? Egal. Ihr werdet bestimmt auch eure Tipps abgeben.
• InvalidArgumentException
  Jetzt wird es wieder einfacher. Jedes mal, wenn ein Argument, also ein Parameter einer Funktion, nicht vom richtigen Typ ist, dann wird diese Ausnahme geworfen. Hatten wir ja schon ausgiebig im Beispiel von Claus.
• LengthException
  Naja wie sinnvoll eine Exception ist, die dafür da ist bei falschen Längen anzuschlagen weiß ich nicht. Auf jeden Fall gibt es sie in PHP. Anwendungsfall könnte hier sein, dass man einen String als Parameter braucht, der einen Ländercode repräsentiert und der muss genau drei Zeichen lang sein. Aber auch da würde ich eine andere Exception werfen.
• LogicException
  “Exception thrown if a logic expression is invalid”. Soviel zu der Beschreibung, die uns php.net liefert. Falls ich einen logischen Audruck habe, der nicht gültig ist, so merkt das doch eigentlich der Interpretor, oder? Komische Sache.
• OutOfBoundsException
  Ok, das macht wieder Sinn. Sobald ich einen Schlüssel habe, der in meinem Array/Objekt nicht gfunden wurde, werfe ich diese Exception.
• OutOfRangeException
  Hier würde ich mal sagen, dass man diese Excpetion verwenden sollte, wenn eine Variable zwar vom gewünschten Typ ist, aber nicht im passenden Wertebereich wiederzufinden ist.
• OverflowException
  Sobald ich einen Container habe, der zu voll wird, bekomme ich eine solche Excpetion vor die Nase geknallt. Macht Sinn. Falls man mal eine Cache Klasse z.B. bauen will, die eine limitierte Anzahl von Elementen halten kann,
• RangeException
  “Exception thrown when an invalid range is given.” Mal wieder keine Ahnung, was mit php.net da sagen will. Vielleicht muss ein Wert in einem bestimmten Wertebereich liegen und wenn er das nicht tut, dann wird was geworfen. Würde aber nicht so perfekt zu der englischen Erklärung passen.
• RuntimeException
  So, hier kann man alles mit kontrollieren was nur während der Laufzeit auftreten kann. Was wäre das zum Beispiel? Der Selenium Treiber wirft glaube ich eine solche Ausnahme, wenn der Kontakt zum Server abegebrochen ist.
• UnderflowException
  Ich versuche aus einem leeren Container etwas zu entfernen und Boooom! Underflow Exception. Oder wir war das noch mal, wenn in ein Haus zwei Leute reingehen, dann drei rausgehen, dann muss erst eine Person reingehen, damit das Haus leer ist.
• UnexpectedValueException
  Ähnlich wie meine Theorie zum Wertebereich bei der RangeException, muss es hier ein Wert aus einem bestimmten Wertesatz sein. Vielleicht alles was vorher über ein Konstante definiert wurde oder ähnliches.

So das waren auch schon dei Exception, die PHP so mit sich bringt. Viele davon halte ich für eher unnötig. Hätte ich selbst vorher nicht gedacht, als ich den Artikel angefangen habe. Trotzdem werde ich die, die ich für sinnvoll erachte auch einsetzen und selbstdefinierten vorziehen. Zumindest werde ich meine Ableitungen besser wählen.

9 Kommentare »

• 
  

  Timo

  am 11. September 2009 um 08:22 Uhr

  Ist das so gewollt?!
  http://www.abload.de/img/exceptions3son.jpg

• 
  

  Alex B.

  am 11. September 2009 um 08:39 Uhr

  Vielen Dank für die Auflistung und die Beschreibungen.

• 
  

  Blackflash

  am 11. September 2009 um 09:15 Uhr

  @DomainException: Ich denke, dass diese Exception geworfen werden soll, wenn ein Wert auftritt, der in der Domäne nicht vorkommen kann/darf, wie z.B. ein Auto mit keinem Rad.
  @RangeException: “Diese Exception wird geworfen, wenn ein ungültiger Bereich übergeben wurde.”

  Sehr gute Übersicht, die sogleich in meine Lesezeichen wandern wird. Es hätte allerdings gut getan, einige Beispiele (aus der SPL) aufzulisten, in denen solche Exceptions geworfen werden – damit könnte man sich den Sinn hinter einigen Exceptions selbst erschließen.

• 
  

  Nils Langner

  am 11. September 2009 um 09:19 Uhr

  @Blackfish Das man einen Berich übergibt ist doch eher eine Ausnahme, glaubst du, dass sie dafür wirklich eine Exception haben? Hast du da vielleicht ein Beispiel gefunden?

• 
  

  Martin Kuckert

  am 11. September 2009 um 10:12 Uhr

  Die RuntimeException und die LogicException sind übrigens Klassen, von denen alle anderen Ausnahmen ableiten. Darum auch so abstrakt, dass du dir den Sinn nur halb erschließen kannst

  Mit der Google Codesuche finde ich auch nur 4 Verwendungen der RangeException, von denen ich nur eine einzige auch so machen würde (http://www.google.com/codesearch?q=%22throw+new+RangeException%22+lang%3Aphp).

• 
  

  Tobias Petry

  am 11. September 2009 um 10:19 Uhr

  LengthException:
  auch Arrays oder ähnliches möglich, man denke nur mal an Verschlüsselungsalgos, die eine bestimmte Bitlänge der Daten erwarten, da könnte man anschlagen, wenn diese nicht erfüllt ist.

  LogicException:
  Dies eine Vater-Exception vieler der hier vorgestellten Exceptions.
  Eine InvalidArgumentException ist ja ein logischer Fehler, der Programmierer hat die Methode mit falschen Daten gefüttert.
  Sollte also auch nur als Exception für Vererbungen und nicht zum direkt-throwen genutzt werden.

  OutOfBoundsException:
  kommt eigentlich aus Java, da wird solch eine Exception geworfen, wenn man auf einen Array-Index zugreift der ausserhalb des Bereichs liegt (Keys dürfen nur integer sein )
  Könnte für die SPL-Klasse ArrayAccess sinnvoll sein.

  OutOfRangeException:
  Könnte man eigentlich auch eine InvalidArgumentException nutzen, hmm.

  RuntimeException:
  Stammt wieder – wie viele dieserExceptions – aus Java. Signalisiert eigentlich Unchecked Exceptions, für PHP relativ nutzlos.

  UnexpectedValueException:
  Könnte man denke ich nutzen, wenn man intern in der Klassen nochmal Daten prüft bevor man mit ihnen rechnet. InvalidArgumentException muss da ja nicht unbedingt passend sein, ist also eher eine Exception die man werfen kann, aber bestenfalls nie geworfen werden sollte xD

• 
  

  Tobias Petry

  am 11. September 2009 um 10:22 Uhr

  @Nils (4): Zend_Validate_Between könnte eine RangeException werfen, denn wenn ich Zahlen im Bereich von [5, -1[ -> (5 <= x < -1) stimmt da eindeutig an dem Bereich etwas nicht.

• 
  

  Blackflash

  am 11. September 2009 um 13:51 Uhr

  @Nils: Ich glaube nicht, ich lese.

• 
  

  KingCrunch

  am 12. September 2009 um 03:42 Uhr

  Jetzt bin doch etwas enttäuscht. Einfach eine Auflistung, wie man sie bei SPL schon findet?
  http://www.php.net/~helly/php/ext/spl/classException.html
  Ich frage mich eher, wie es sinnvoller sein mag: Exceptions mit sprechendem Namen, wie die hier angesprochenen, oder wie man sie bei Java findet, oder “sprechende” Exceptions, bei denen das Problem “Underflow” usw in der Message steht. Wenn man letzteres mit Exception-Codes kombiniert, find ich das persönlich nett, allerdings ist Ersteres bei ausgiebigem Gebrauch der try-catch-Blöcke praktischer.

  So eine Diskussion hätte ich mir jetzt eher gewünscht. Ich les nochmal den alten Thread, vielleicht find ich da ja noch was

  Grüße,
  Sebastian

RSS-Feed für Kommentare zu diesem Artikel. TrackBack-URL

Einen Kommentar hinterlassen