nicht angemeldet
Moin!
Eine Frage noch, zu einer evtl. Exceptionklasse.
Wenn du dir eigene Exception-Klassen definierst, kannst du den Code in jeder eigenen Exception fest definieren, erhältst zusätzlich noch einen netten, beschreibenden Namen, könntest die Message um beschreibende Standardtextkomponenten anreichern etc.
Und erst damit kriegst du auch die Möglichkeit, auf unterschiedliche Exceptions mit unterschiedlichen catch-Blöcken zu reagieren. Das mag überdimensioniert klingen, aber ich finde es ziemlich gut, wenn man das einsetzen kann, wenn man es braucht.
Ich habe auch schon mal kurz mit dem Gedanken gespielt, die Codes (nr.) zu verwenden. Ich kam aber darauf, dass es dann sehr wichtig ist, dass jede Nummer nur exakt einmal in dem ganzen Projekt vorkommt, sonst gibt es ja richtige Falschmeldungen. Ist das nicht wahnsinnig schwer zur warten? Ich bin sicher, dass es da nochwas gibt, was ich nicht weiß.
Wenn es darum geht, festzustellen, woher eine Exception kommt: Die Exception bringt den gesamten Stacktrace sowie die Datei und Zeilennummer mit, in der sie geworfen wurde.
Einen EIGENEN Error-Code habe ich in meinen Exceptions noch nie verwendet. Wohl aber habe ich den Error-Code von MySQL dort schon reingetan: Mysql-Funktionsaufruf liefert einen Fehler, mein DB-Layer wirft eine Exception (und zwar eine Db_Exception) mit Error-Message und Error-Code der MySQL-Fehlermeldung.
Bonus-Gimmik: Weil das Erkennen von "Duplicate Key Violation" in der DB als Besonderheit und "ist gar kein böser Fehler" behandelt werden musste, hat die Db_Exception eine neue Methode "isDuplicateKey()" bekommen, die den gesetzten Fehlercode mit dem für diesen Duplicate-Key-Fehler vergleicht und ggf. true zurückgibt. Dadurch kann ich erstmal ein INSERT versuchen und ohne viel Brimborium im catch mit if ($e->isDuplicateKey()) ein nachträgliches UPDATE hinterherschieben.
- Sven Rautenberg