Exceptions

Exceptions heißen übersetzt „Ausnahmen“. Das bedeutet, dass eine Exception durch eine nicht normale Situation hervorgerufen wird. Für die Definition einer nicht normalen Situation gibt es wiederum verschiedene Ansätze:

  • Der bequeme Ansatz geht nur von „happy path“ aus, alle Abweichungen davon sind Exceptions
  • Der extreme Ansatz kann auf alle Situationen entweder technisch oder fachlich reagieren und benötigt keine Exceptions

Der extreme Ansatz ist in der Praxis nicht möglich, erstens können nicht alle Fehler vorhergesehen werden, und zweitens können bei der Kompensation von Fehlern wiederum Fehler auftreten, somit ergibt sich ein endloses Programm. Der bequeme Ansatz kommt durchaus in der Praxis vor, er bürdet aber alle Verantwortung dem Aufrufer auf und ist somit unbeliebt. Zwischen diesen beiden Extremen liegt der pragmatische Ansatz, der eine praxisgerechte Mischung beider Konzepte ist.

Folgende Regeln helfen mir, einen gesunden Ansatz zu finden:

  • Eine Exception wird nie zur direkten Kontrolle des Programmflusses benutzt
  • Eine Exception bedeutet eine Situation, auf die nicht angemessen reagiert werden kann, das Werfen einer Exception verlagert dann die Reaktionsmöglichkeit in den Aufrufer
  • Aus Sicht des Clients kann eine Exception überall im try-Block eines try-catch-finally Statements auftreten, also kann der Kontrollfluss beim Auftreten der Exception irgendwo im try-Block stoppen und im catch-Block fortfahren. Der catch-Block stellt wieder einen konsistenten Zustand her
  • Jede Exception beinhaltet eine treffende Beschreibung der Ausnahmesituation
  • Exception-Handling wird nicht nachträglich eingefügt, sondern von Anfang an bei der Entwicklung berücksichtigt

Exceptions können nach unterschiedlichen Gesichtspunkten klassifiziert werden. Da für die Komponente, welche die Ausnahme wirft, alle Klassifizierungen „richtig“ sind, ist bei der Wahl der Klassifizierung auf die Bedürfnisse des Aufrufers Rücksicht zu nehmen. Für Klassifizierungsbeispiele siehe folgendes Bild.

Exceptions

Wird eine JEE-Applikation entwickelt, so erhalten die Exceptions eine zusätzliche Semantik bezüglich der Transaktionssteuerung: RuntimeExceptions, die eine ApplicationException-Annotierung besitzen und Checked-Exceptions bedeuten eine Fortsetzung der Transaktion. Fliegen hingegen RuntimeExceptions ohne spezielle Annotierung über EJB-Grenzen, so wird die Transaktion zurückgerollt. Bei der Entwicklung von EJBs ist diese Semantik immer zu berücksichtigen.

Generell gilt: Bei dem Design von Exceptions muss über Kompoententengrenzen hinweg gedacht werden, da die Bedürfnisse und Reaktionsmöglichkeiten der Aufrufers ebenfalls zu berücksichtigen sind.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.