Wie am besten Fehlermeldungen handlen

[Sven Rautenberg]

Moin!

1. Der User klickt
2. Der Controller wird aufgerufen
3. Das UserModel wird aufgerufen
4. Es wird eine Query erstellt
5. Diese Query wird der Klasse für die Datenbankverbindung übergeben.

Innerhalb der Reihenfolge werden verschiedene Objekttypen untereinander weitergegeben oder zurückgegeben.

Nun frage ich mich, wenn ich in der Ebene 5 eine Exception auswerfe, dass der Datenbanktreiber nicht gefunden wurde, dann kann es die Ebene 4 abfangen, falls in Ebene 5 eine Exception passiert. Die Exceptionmeldung muss aber Standarisiert dann bis zum Controller zurück, der dann die Meldung dem User geben kann. (Ich schaue mir mal an, wie ich das mit den Exceptions noch geschickt einbauen könnte)

Nein, WENN die Exception aus der Datenbankklasse gefangen wird, darf sie nicht ganz bis zur obersten Ebene gelangen. Aber du darfst natürlich eine neue Exception werfen, die das Problem in einem anderen Licht betrachtet, und die dann vielleicht nach ganz oben wandert.

Sollte sie wiederum gefangen werden, wäre eine neue, für diesen neuen Kontext geeignete Exception zu werfen.

Könnte ich eine Klasse mit statischen Klassenvariablen wie zum Beispiel errorCode und errorText (String wenn nur der letzte Fehler gespeichert oder Vector wenn mehrere) schreiben.
Könntest du schon auch. Aber das ist doch umständlich zu handhaben.
Exceptions sind genau dazu da, was du vor hast.

Also prinzipiell wäre es mit statischen Klassenvariablen auch möglich?

Exceptions sind exakt das, was du brauchst. Vor allem, da sie genau das tun, was man im extremen Fehlerfall tun will: Die Ausführung an der aktuellen Stelle abbrechen und soweit zurückspringen, dass irgendein sich zuständig fühlender Catch-Codeteil die Verarbeitung übernimmt, andernfalls aber halt die Exception bis zum User vordringt.

Wenn eine Datenbank nicht antwortet, und der User von der DB Daten wollte, kann man das Problem halt "nackt" lassen, oder in nette Worte verpacken. An der Tatsache, dass die DB nicht antwortet, ist aber nix zu ändern.

Üblicherweise baut man sich zwecks feiner granulierter Catch-Routinen einen eigenen Baum von Exceptions, die alle von der Standard-Exception erben und ihrerseits das eventuell auftretende Problem feiner beschreiben - für den Fall, dass eine Unterscheidung des Problems grundsätzlich möglich und hilfreich ist.

Sprich: Zuallererst brauchst du mal "DeineException" als Erben von der allgemeinen "Exception", damit du alle deine selbstgebauten Exceptions unterscheiden kannst von Exceptions anderer Komponenten.

Und davon erben dann eventuell benötigte feiner aufgeteilte Exceptions, die dein Code in speziellen Situationen werfen könnte.

Und dein Frontcontroller fängt dann als letzte Ebene alle Exceptions, die bei der Ausführung auftreten könnten, und kann dann unterscheiden zwischen deinen eigenen Exceptions (die vielleicht nicht so böse sind, und deshalb eine nette Fehlermeldung anzeigen, in deinem eigenen Design), und allen anderen Exceptions, die er deshalb mit Serverstatus 500, nur einer Standardmeldung sowie einem geschriebenen Logfile beantwortet.

Wenn man eine Klassenvariable "public static int errorCode=null" hätte dann könnte ich doch von überall aus in der Applikation durch Klassenname.errorCode=1 ja einen neuen Wert zuweisen können, wo dann später jede Klasse diese Klassenvariable abrufen oder einen neuen errorCode überschreiben könnte?

Warum erfindest du etwas neu, was es in vernünftiger Form schon gibt? :)

- Sven Rautenberg