WebApp - Spring / Exceptions - Verständnisfrage

[DerGrinsemann]

Hallo!

Ich bastle seit einiger Zeit an meiner ersten WebApp auf Basis von Spring 2, Spring MVC und Hibernate 3.

Dabei habe ich mich für folgenden Aufbau entschieden:

Controller <-> (DTO) <-> Service <->DAO <-> Domain

Nun grüble ich darüber nach "wo" ich "welche" Exceptions weiterleite, werfe und abfange.

Gefühlsmässig alles unterm Service (also DAO und im Domain) im Service abfangen und eigene Exceptions (z.B. PersonNotFoundException) im Controller - geworfen durch Service.

Wie macht Ihr das?

Marco

 

[Oliver Gierke]

Grundsätzlich sicher richtig. Der Rest ist eigentlich auch schon Geschmackssache.

Beim Exceptiondesign ist es sinnvoll aus Clientsicht zu denken. D.h. für die Exceptions des DAO Layers überlegst du dir, auf welche Fehlertypen der Servicelayer wie reagieren müsste.

Grundsätzlich gibt es halt auch zwei verschiedene Designwege: Exception per Case (wie deine PersonNotFoundException) oder Exception per Component (CustomerManagerException für deinen Service CustomerManager). Ich starte meist mit dem Exception per Component weg. Einfach weil sich dann nicht so schnell Exceptionklassen anhäufen. Viele Fehlerfälle kann man dann durch Messages beschreiben und die so hochreichen. Wenn der Fall eintritt, dass man im Client plötzlich doch was spezielleres haben will, kann man dann immernoch zusätzliche Exceptions einführen, die evtl noch extra Parameter tragen und diese Exc. dann von der BasiskomponentenException ableiten (was das Handling etwas erleichtert) oder halt separat daneben legen. Ab und zu macht es auch Sinn für Layer eine Basisexception einzuführen - SeviceException z.B. (obwohl dann das Exceptiondesign sehr von der Technik getrieben ist... eigentlich immer unschön)

Sehr wichtige Frage ist dabei auch, wie und vor allem wo du Exceptions fangen willst. Hier kann man z.B. mit AOP ansetzen und zwischen den Layern ExceptionHandling Aspekte einführen.

Ich bin momentan auf dem trip eher Unchecked Exceptions zu benutzen und diese dann über einen zentralen ExceptionHandler abzufangen. Checked Exceptions machen meiner Meinung nach wirklich nur Sinn, wenn der direkte Client damit was anfangen kann (ausser sie in eine fachliche Exception zu wrappen).

Gruß
Ollie

 

[DerGrinsemann]

Hallo!

Danke für deine Antwort! Möchte aber nochmals genauer nachfragen.

Ich bin momentan auf dem trip eher Unchecked Exceptions zu benutzen und diese dann über einen zentralen ExceptionHandler abzufangen. Checked Exceptions machen meiner Meinung nach wirklich nur Sinn, wenn der direkte Client damit was anfangen kann (ausser sie in eine fachliche Exception zu wrappen).

Wie löst du das mit dem "zentralen ExceptionHandler"? Hast du vielleicht ein Code-Schnippsel für mich?

Marco

 

[Oliver Gierke]

Klassische (um nicht zu sagen Legacyanwendungen) haben sowas wie nen try / catch Block , der Exception oder Throwable catcht und zwar an zentralen Einstiegspunkten der Anwendung (MDB o.ä.).

Eleganter ist natürlich die Nutzung von AOP und ein Aspekt, der ein Throws-Advice nutzt um alle Exceptions der öffentlichen Schnittstelle zu fangen. Sprich, ein Pointcut, der die öffentlichen Methoden der Anwendung selektiert (z.B. die Interfaces deines Servicelayer) verbunden mit Throws-Advice, der dann ausgeführt wird, wenn die Exception fliegt.

Ein paar Beispiele (wenn auch z.T. in .NET) findest du hier:

http://www.codeproject.com/useritems/ExceptionHandlingWithAOP.asp
http://geekswithblogs.net/imilovanovic/articles/11585.aspx
http://static.springframework.org/spring/docs/2.0.x/reference/aop.html