News

Donnerstag, 2. Dezember 2010 | News

10 typische Fehler in Enterprise-Java-Anwendungen

(Link zum Artikel: http://www.it-republik.de/jaxenter/news/057701)
  • Teilen
  • kommentieren
  • empfehlen
  • Bookmark and Share

Wenn man öfter Code-Reviews macht, fällt einem nach einiger Zeit auf, dass man immer wieder dasselbe sieht. In dieser Session von der W-JAX 2009 zeigt Eberhard Wolff zahlreiche typische Fehler in Enterprise-Java-Anwendungen auf, die zudem kritische Auswirkungen haben können - und natürlich auch, wie man sie vermeidet.

10 typische Fehler in Enterprise-Java-Anwendungen from JAX TV on Vimeo.

(hs)

andere Artikel dieser Serie

Anzeige

Kommentare

Gravatar james 03.12.2010
um 09:12 Uhr Sehr guter Beitrag!!! Bitte mehr davon! #zitieren
Gravatar manolo 03.12.2010
um 10:27 Uhr Finde ich auch. Interessanter Vortrag! Gut, manchmal eine "Werbeveranstaltung" für Spring. Aber wer will es dem Redner verdenken. Schließlich verdient er damit seine Brötchen... ;) #zitieren
Gravatar Eberhard Wolff 03.12.2010
um 11:43 Uhr Danke für das positive Feedback - freut mich! #zitieren
Gravatar jsimon 05.12.2010
um 15:02 Uhr Kann ich nur zustimmern. Würde vor allen auch gern mal die 10 größten Performance-Fallen sehen (Da ich da bei komplexen Projekten große Probleme sehe) #zitieren
Gravatar Mirko 10.12.2010
um 09:34 Uhr Guter Beitrag trotz der kleinen Ecken und Kanten. Man sieht deutlich die praktische Seite durchschimmern. Der Beitrag ist ein guter Ausgangspunkt um über seinen eignen Code nach zu denken. #zitieren
Gravatar Simon 06.01.2011
um 20:05 Uhr Vielen Dank für das aufschlussreiche Video! Sehr gerne würde ich mich weiteres Videomaterial von Ihnen anschauen.

Grüße #zitieren
Gravatar raksch 07.01.2011
um 22:58 Uhr Das mit den checked Exceptions kann ich so nicht befürworten. Checked Exceptions zwingen den Entwickler dazu auf einen Fehler zu reagieren was auch gut ist. In den Projekten in denen ich bisher gearbeitet habe wurden Exceptions immer bis zur Oberfläche weitergegeben, damit der Benutzer/Tester sofort bescheid weiss, dass etwas schief gelaufen ist. Ich mein es gibt nichts schlimmeres als einen Fehler einfach zu verschlucken und der User sitzt wie ein Blödmann vorm Rechner und drückt immer wieder den selben Button weil nicht vernünftiges passiert. Irgendwie realitätsfern das Beispiel.
Wo ich zustimmen kann, ist, dass man nicht so viele eigene Exceptions schreiben sollte. #zitieren
Gravatar raksch 07.01.2011
um 23:01 Uhr Das erste Beispiel finde ich auch nicht besonders relistisch. Man muss schon ziemlich einfach gestrickt sein, wenn man bewusst eine Transaktion öffnet ohne potentielle Fehler abzufangen um dann ein RollBack durchführen zu können. Das macht imho keinen Sinn, gibt es wirklich viele Entwickler die so etwas tun? #zitieren
Gravatar Eberhard Wolff 09.01.2011
um 11:46 Uhr @raksch : Danke für das Feedback!

Zu den Exceptions: Die Präsentation plädiert genau wie Sie dafür, Fehler ganz nach oben durchzugeben. Das ist bei unchecked Exceptions auch der Default. Wenn man mit checked Exceptions einen Fehler nach oben durchgeben will, muss man das auf jeder Schicht mit throws deklarieren, was ich für overhead halte.

Die echte Behandlung einer Exception, zu der der Entwickler mit checked Exceptions gezwungen werden soll, halte ich für die Ausnahme. Wenn man eine Exception sinnvoll behandeln kann, müsste sie dem Anwender wahrscheinlich gar nicht gezeigt werden. Die Anwendung geht selber mit ihr um. Das abschreckende Beispiel bzgl. der Exception-Regeln basiert übrigens auf einem realen Projekt...

Das Beispiel mit den Transaktionen ist tatsächlich so in einem Code Review aufgetaucht (war auch wirklich eine sehr kurze Methode). Ich finde bei Reviews immer wieder Fälle, bei denen Ressourcen oder Transaktionen nicht im finally-Block geschlossen werden. Natürlich ist das oft etwas versteckter. Das ist vielen Entwicklern als Fehlerquelle einfach nicht präsent. Da Fehler beim Aufräumen einer Ressource oder beim Beenden einer Transaktion so dramatische Folgen haben können, habe ich es in die Präsentation aufgenommen. Neben den Templates in Spring gibt es auch Verbesserungen in Java 7 dazu (siehe http://blogs.sun.com/darcy/entry/project_coin_arm_apil ) und Scala hat auch ein analoges Konzept IIRC. Das zeigt, dass es ein sehr reales Problem ist... #zitieren
Gravatar raksch 10.01.2011
um 23:19 Uhr Hallo Eberhard Wolff,

dass eine Anwendung sinnvoll mit einer Exception umgehen kann halte ich auch eher für die Ausnahme. Ich bin mir auch nicht ganz sicher was besser ist, entweder wie in ihrem Vortrag auf eine allgemeine Fehlerseite zu navigieren, dann könnte man wirklich vieles an Code einsparen wie im Vortrag zu sehen oder so wie ich es tue, die Fehlermeldung auf der Seite anzuzeigen wo sie aufgetreten ist. Da kann man sich sicherlich drüber streiten. #zitieren
+ Neuen Kommentar verfassen

Folgende Links könnten Sie auch interessieren

zurück zum Seitenanfang