Exception im Konstruktor / Objekt == null

[Krabat]

Folgendes Problem:
Wenn ich in meinem Constructor eine Exception werfe, scheint das Object meiner Klasse nicht erzeugt zu werden, stattdessen bleibt es null. Ist es möglich eine exception im constructor zu werfen und trotzdem das Objekt regulär zu erzeugen?
Was wäre, wenn ich erst in der Methode init die Exception werfen würde?

public Log(int filterLv) throws LogInitException {
            // überprüft, ob der parameter filterlevel in den legalen Grenzen liegt
	    if (filterLv >= ALL_LEVELS_MIN && filterLv <= ALL_LEVELS_MAX) {
		    fatalError		= false;
		    init(output);
	    } else {
	        fatalError = true;
            throw new LogInitException(
	        "Filter Level out of Range! Legal range: " +
	        ALL_LEVELS_MIN + " - " + ALL_LEVELS_MAX);
        }
}

 

[Beni]

Falls eine Methode eine Exception wirft, kann sie keinen Rückgabewert zurückgeben, da sie nie ein "return" erreicht.

Mit einem Konstruktor passiert dasselbe: der Rückgabewert - das neue Objekt - kann nicht zurückgegeben werden.

Du kannst natürlich innerhalb des Konstruktors einen try-catch-Block machen, aber allgemein gilt: falls etwas eine Exception wirft, muss man entsprechend den veränderten Umständen reagieren...

(Du könntest zwar direkt im Konstruktor "this" auf z.B. eine statische Variable abspeichern, aber diese Lösung ist dann doch ein sehr seltsames Design.)

 

[Krabat]

hmmm....

es geht mir darum, dass das Logging Tool als komplettes Paket weiter in weiteren Projekten einsetzbar sein soll. Tritt ein Fehler bei der Initialisierung auf, soll eine Exception geworfen werden.
Trotzdem gibt es im Programm viele weitere Aufrufe des Logs, die dann versuchen eine Methode von einem Objekt zu erzeugen, welches null ist. Um dies zu umgehen, dachte ich mir, diesen einen boolean "fatalError" zu setzen, der dafür sorgt, daß die LogMessages einfach nichts mehr tun. Leider bleibt noch immer das Problem, daß das Objekt null ist.

Wie könnte ich das schlauer lösen?

 

[Beni]

Wirf gar keine Exception. Dann hast du eine beschädigte Instanz, aber in diesem Fall besser als gar keine.

Ich würde den Konstruktor erweitern auf:

public Log(int filterLv, boolean throwException) throws LogInitException{
       if (filterLv >= ALL_LEVELS_MIN && filterLv <= ALL_LEVELS_MAX) {
          fatalError      = false;
          init(output);
       } else {
           fatalError = true;

           if( throwException ){  // falls der Client eine Exception wünscht: bitte soll er sie haben. Ansonsten geht es hier ganz normal weiter
               throw new LogInitException(
                "Filter Level out of Range! Legal range: " +
               ALL_LEVELS_MIN + " - " + ALL_LEVELS_MAX);
            }
        } 
}

Dann kann später der Programmierer entscheiden, ob er eine Exception (und damit einen null-Logger) oder keine Exception, dafür ein halb-funktionierendes Ding haben will.

daß die LogMessages einfach nichts mehr tun.

Ich würde irgendwo eine riesige Warnlampe aufstellen (JOptionDialog oder so, ERROR_MESSAGE), und das Problem nicht unter den Teppich kehren :wink:

 

[Roar]

mach doch einfach eine factory methode public static Log createLog(Bla param) throws BlaException

so wird entweder eine exception geworfen oder das objekt wird zurückgelifert, und der benutzer der methode weiß das..

 

[Krabat]

Danke für Eure Anregungen.

Ich finde es wichtig, daß eine Exception geworfen wird, damit deutlich wird, dass etwas schief gelaufen ist. Damit aber weiterhin auf das Log Objekt zugegriffen werden kann (weil die log Aufrufe im ganzen Programm verteilt sind), darf es nicht null sein, also keine Exception im Konstruktor geworfen werden.

Also wird es wohl (beim Aufruf) auf sowas rauslaufen...

...
try {
    Log log = new Log();  // hier kann keine Exception geworfen werden
    log.init(paras...);       // hier wird evtl. eine Exception geworfen
}
catch (...) {...} ...

Finde ich persönlich zwar nicht sonderlich schön, aber ich sehe zur Zeit nur diese Möglichkeit und die vo Beni vorgeschlagene.



Das mit der FactoryMethode finde ich auch sehr interessant, habe es mir durchgelesen, aber trotzdem muss (für meinen Fall) erst ein instanziiertes Objekt vorhanden sein, oder? Wenn man als einzigen Aufruf hat...

public static Log createLog(Bla param) throws BlaException

...und es wird eine Exception geworfen, ist das Objekt wieder null, oder?

 

[Krabat]

Oh!

oder das ganze in den catch block:

...
try {
    Log log = Log.createLog(paras...);     // hier wird evtl. eine Exception geworfen
}
catch (LogInitException) {
    log = new Log();                  // hier kann keine Exception geworfen werden
} ...

...ist aber auch nicht so ganz astrein vom design....

 

[Tobias]

Zu diesem Problem gibt es sogar ein Pattern: Special Case oder Null Objekt (je nach Autor).

Lagere die Signaturen der Mathoden in ein Interface aus. Lege eine Implementierung des Interfaces an, die nichts tut - das Null-Objekt und ein Implementierung, die das tut, was eigentlich vorgesehen ist. Sollte jetzt bei der Instanziierung des letzteren Objekts etwas schief gehen, hast du immer noch das Null-Objekt, das zwar nichts tut, aber definitiv Exceptions vermeidet.
In einem Buch fand ich den Hinweis, man möge den Nullfall doch als anonyme innere Klasse des Interfaces anlegen; mit folgendem Code-Beispiel:

public interface Interface {

    public void something();

    public static NullObject NULL = new NullObject() {
        
        public void someMethod() {
            // does nothing
        }
    }
}

mpG
Tobias