Leichtgewichtige JEE Entwicklung mit dem Spring Framework

Leichtgewichtige JEE Entwicklung mit dem Spring Framework

Posts 11-15 of 15
  • Eberhard WolffEberhard Wolff is a contact of your contacts
    Eberhard Wolff    Group moderator
    The company name is only visible to registered members.
    Re^8: Exceptions in der init-method
    Halo,

    aus meiner Sicht gibt es hier zwei Themen:
    - Warum wird die Exception geworfen? Sie sollte nur geworfen werden, wenn das Objekt nicht sinnvoll initialisiert werden kann, weil ein Konfigurationsfehler vorliegt oder ähnliches. Sonst sollte man tatsächlich keine Exception werfen - weder in der init-Methode noch im Konstruktor.
    - Wenn aber die Initialisierung des Objekts nicht sinnvoll erfolgen kann und anschließend keine sinnvolle Nutzung möglich ist, würde ich die Exception tatsächlich frühzeitig werfen, damit man die Fehlersituation frühzeitig erkennen kann. Wieso sollte man das verzögern, wenn es am Ende doch schief gehen wird? Man erreicht maximal, dass der Fehler bis zum ersten Methodenaufruf verzögert wird.
    - Soweit spielt Spring keine Rolle, es geht nur um objekt-orientierte Programmierung - das ist auch ein wichtiger Hinweis - vielen Dank! Allerdings ist es sinnvoll, dass bei Spring der ApplicationContext nicht hochfährt, wenn ein Objekt nicht initialisiert werden kann - das System kann eben nicht initialisiert werden.
    - Der Hinweis auf Constructor Dependency Injection habe ich nur eingeflochten, weil das eben auch bei programmatischer Nutzung funktioniert und ich im Beispiel das Gefühl habe, dass man Constructor Dependency Injection gut nutzen könnte. Es wahr wohl eher dem geschuldet, dass ich das Gefühl habe, dass Constructor DI oft unberechtigterweise vernachlässigt wird .

    Schönes Wochenende!

    Eberhard Wolff
    • 05 Jun 2009, 5:40 pm
  • Dagmar Buggle
    Dagmar Buggle    Premium Member
    The company name is only visible to registered members.
    Re^9: Exceptions in der init-method
    Vielen Dank für die vielen ausführlichen Diskussionsbeiträge! Ich kann nur von allen lernen...

    gruß
    Dagmar
    • 05 Jun 2009, 6:08 pm
  • Oliver Gierke
    Oliver Gierke    Premium Member
    The company name is only visible to registered members.
    Re^8: Exceptions in der init-method
    Dr. Siegfried Sauter-Fischer schrieb:
    Ich sehe nur die Möglichkeit, eine solche Situation streng zu vermeiden, d.h. eine Exception niemals in irgendwelchen Konstruktoren, Init- oder PostConstruct-Methoden zu werfen. Hierfür sehe ich zwei offensichtliche mögliche Ansätze:
    Das sehe ich komplett anders. IMHO ist es wichtig, Fehler so früh wie möglich zu reporten. Was ist z.B. mit invaliden Konstruktorparametern? Exceptions ind hier genau das richtige Mittel eine Unkonstruierbarkeit des Objektes zu signalisieren.

    Ich halte es auch für sinnvoll, sich auf Konstruktor DepenencyInjection zu konzentrieren. Man kann so gut zwischen unbedingt benötigten und optionalen Dependencies unterscheiden, indem man für erste Konstruktorparameter benutzt und für letztere eben Setter. Erst hier bekommt man das Problem, das komplette Objekt nach dem Setzen der Properties auf den Settern erst in einer zusätzlichen Initmethode validieren zu können.

    Insgesamt gilt es daher einfach im Team eine Vereinbarung auf ein bestimmtes Vorgehen zu treffen und das konsistent durchzuhalten.

    Gruß
    Ollie
    • 06 Jun 2009, 3:54 pm
  • Dr. Siegfried Sauter-Fischer
    Dr. Siegfried Sauter-Fischer
    The company name is only visible to registered members.
    Re^9: Exceptions in der init-method
    Hallo,

    mit meiner Aussage war ich etwas voreilig. Ich nehme sie daher zum großen Teil zurück.

    Irgendwie war ich auf ein temporäres Problem fixiert. Falls man annehmen kann, dass die Fehlersituation nur temporärer Natur ist - wie es zum Beispiel bei einer Nichtverfügbarkeit irgendeiner Schnittstelle der Fall sein könnte - so halte ich es nach wie vor das beste, eine Selbstheilung einzubauen. In diesen Fall sollte keine Exception in der init-Methode fliegen. Statt dessen sollte das Problem auf später verlagert werden und mit einer qualifizierten Fehler-Reaktion abgefangen werden, z.B. indem die Meldung über eine temporär nicht verfügbare Schnittstelle ausgegeben wird.

    Solch eine Fehlertoleranz ist insbesondere bei hochgradig vernetzten Systemen wichtig, damit man beim Hochfahren eines Systems nicht auf die Partnersysteme angewiesen ist und eventuell noch nicht einmal mehr eine valide Reihenfolge zum Hochfahren findet.

    Der Ausschnitt aus dem Applikations-Kontext, den Frau Buggle im Re^2 geliefert hat, deutet aber an, dass es sich um ein Problem beim Lesen oder Parsen eines Konfigurations-Files handelt. In diesem Fall wäre das Problem vermutlich permanent.

    Es ist natürlich nicht sinnvoll eine VM hoch zu ziehen, die permanent unbenutzbar ist. Ist zu erwarten, dass ein bestimmte Fehlersituation permanent existiert, so ist ein frühzeitiger Abbruch mit qualifizierter Fehlermeldung die beste Lösung. Ich gebe daher Herr Gierke recht, dass in solch einen Fall die Unkonstruierbakeit eines Objekts früh signalisiert werden sollte.
    • 08 Jun 2009, 10:33 am
  • Post visible to registered members