Null-Pointer trotz Konstruktor?

[Wuast]

Hallo liebe Leute,

kann mir jemand mal eben flott darlegen, warum ich hier bei dem "peter" eine Null-Pointer Exc bekomme? Steh gerade etwas auf dem Schlauch.

public class WorkerGeneralManagement {
    
    public static void main(String[] args) {

        Worker peter = new Worker();
        peter.setName("Peter");
        
        peter.setExtraPayedVacation(2);    //Peter erhält 2 Zusatztage Urlaub
        
        Facade_WorkerDataManamgement facade = new Facade_WorkerDataManamgement(peter);
        
        facade.setTknDays(4);    //Peter nimmt 4 Tage Urlaub
        facade.setTknExtraDays(1);    //Peter nimmt einen Zusatztag Urlaub
        facade.calcDaysNotAtWorkInTotal();
    }
}

public class Worker {
    private String name;
    private double totalDaysOff = 30.0;
    private double extraPayedVacation = 0.0;    //für Peter sind es 2
    //weitere Instanzvariablen und getter & setter
}

public class Facade_WorkerDataManamgement {

    Worker worker;
    private double tknDays;
    private double extraDays;
    
    Facade_WorkerDataManamgement (Worker newWorker){    //hier kommt der Peter an
        this.worker = newWorker;
    }
    
    CalculateLeftAmountOfDaysOff calcDaysOff = new CalculateLeftAmountOfDaysOff(worker);    //hier wird der Peter übergeben
    CalculateExtraPayedVacation calcExtraOff = new CalculateExtraPayedVacation(worker);

    
    public void setTknDays (double newTknDays) {
        this.tknDays = newTknDays;
    }
    
    public void setTknExtraDays (double newExtraDays) {
        extraDays = newExtraDays;
    }
    
    public double calcDaysNotAtWorkInTotal() {
        //Methodeninhalt
    }   
}


public class CalculateLeftAmountOfDaysOff {

    Worker worker;
    
    CalculateLeftAmountOfDaysOff (Worker newWorker){    //über die facade wird hier doch dann ebenfalls der Peter übergeben
        this.worker = newWorker;
    }
    
    private double totalAmnt = worker.getTotalDaysOff();     //hierauf verweist die Exception: worker is null?
    
    public double calculateOffDaysLeft (double tknAmnt) {
        //Methodeninhalt
    }
}

Konsolenausgabe:
java.lang.NullPointerException: Cannot invoke "facadePattern.Worker.getTotalDaysOff()" because "this.worker" is null
at FPattern//facadePattern.CalculateLeftAmountOfDaysOff.<init>(CalculateLeftAmountOfDaysOff.java:11)
at FPattern//facadePattern.Facade_WorkerDataManamgement.<init>(Facade_WorkerDataManamgement.java:13)
at FPattern/facadePattern.WorkerGeneralManagement.main(WorkerGeneralManagement.java:13)


Danke

 

[KonradN]

Sorry, aber die Art und Weise ist extrem schwer nachzuvollziehen! Bei so einem Stacktrace will man sehen, wo was statt findet und die Zeilennummern matchen da ja nicht. Also bei sowas alle Dateien komplett bringen!

Ansonsten schau Dir an, in welcher Reihenfolge eine Klasse initialisiert wird!

public class Facade_WorkerDataManamgement {

    Worker worker;
    
    Facade_WorkerDataManamgement (Worker newWorker) {
        this.worker = newWorker;
    }
    
    CalculateLeftAmountOfDaysOff calcDaysOff = new CalculateLeftAmountOfDaysOff(worker);    //hier wird der Peter übergeben
}

Der Konstruktor wird erst nach der Initialisierung von der Instanzvariable durchlaufen. worker ist also zum Zeitpunkt der Initialisierung von calcDaysOf noch null und daher die NPE.

Das was Du da auch machst ist ein absolutes No-Go: In einer Instanzvariable Initialisierung sollte man darauf verzichten, andere Instanzvariablen zu nutzen. Das führt zu genau diesem Müll.
Und halte die Klasse sauber, d.h. sortiere die Elemente in der Klasse. Instanzvariablen sollten zusammen bleiben und nicht aufgeteilt teilweise vor Konstruktor und teilweise nach dem Konstruktor.

 

[Wuast]

Sorry, aber die Art und Weise ist extrem schwer nachzuvollziehen! Bei so einem Stacktrace will man sehen, wo was statt findet und die Zeilennummern matchen da ja nicht. Also bei sowas alle Dateien komplett bringen!

Meinst du noch die aaskommentierten Punkte?
Abgesehen davon habe ich alles hier reingepostet was ich dazu habe, außer noch das Pendant zu CalculateLeftAmountOfDaysOff, nämlich

public class CalculateExtraPayedVacation {

        Worker worker;
        
        CalculateExtraPayedVacation (Worker newWorker){
            this.worker = newWorker;
        }
        
        private double daysLeftExtraVac = worker.getExtraPayedVacation();
        
        public double calculateExtraVacLeft (double tknAmnt) {
            
            if (daysLeftExtraVac >= tknAmnt) {
                daysLeftExtraVac -= tknAmnt;
                System.out.println("Vacation request accepted. Amount of days off left is: " + daysLeftExtraVac);        //testing purpose
                return daysLeftExtraVac;
            }
            else {
                System.out.println("Extra payed vacation could not be accepted. Amount of days off left here is: " + daysLeftExtraVac + ", amount of days off requested is :" + tknAmnt);
            }
            return (Double) null;
        }
}

hier jetzt mit Methodeninhalt.

Der Konstruktor wird erst nach der Initialisierung von der Instanzvariable durchlaufen. worker ist also zum Zeitpunkt der Initialisierung von calcDaysOf noch null und daher die NPE.

Hmm.. nur für mich zum Verständnis: Ich erzeuge doch das Objekt dieser Klasse mithilfe des Konstruktors und soweit mich gelehrt wurde stellt der Konstruktor dann eine Art "State" dar, in der die Klasse erzeugt wird. D.h. aber doch dann, dass die Objekterzeugung stattfindet und dann direkt alle Instanzvariablen erzeugt werden, und DANN erst die Initialisierung über den Konstruktor abläuft, oder?
Ich habe nämlich extra die calcDaysOff nach unten verschoben, weil ich dachte: Dann habe ich den Yorker, der wird initialisiert über den Konstruktor und dann kann ich ihn an calcDaysOff übergeben und die instanziieren

Um dein No-Go zu killen, muss ich dann den Konstruktor in den Cclc-Klassen ändern und diese entsprechend umschreiben, sehe ich das richtig? Danke für den Hinweis jedenfalls schonmal.

 

[mihe7]

Instanzvariablen sollten zusammen bleiben und nicht aufgeteilt teilweise vor Konstruktor und teilweise nach dem Konstruktor.

@Wuast, das sind übrigens Dnige, die man sich unbedingt angewöhnen sollte. Genauso wie man Methoden keine irreführenden Namen geben sollte.

Da kannst Du richtig viel Spaß damit haben. In einer App hatte ich mal Code der Form

List<Person> persons = repo.getPersons();

und die IDE zeigte an: Variable persons wird nirgends benutzt. Da ich am Säubern des Codes war, flog die Zeile natürlich raus, denn warum soll ich aus dem Repository Personen abrufen, wenn sie dann nirgends benutzt werden?!?

Hinterher funktionierte gar nix mehr und weil das nicht die einzige Änderung war, fing die Fehlersuche an, richtig lustig zu werden. Am Ende stellte sich raus: öh, repo.getPersons() rief nicht einfach die Personen aus der DB ab, sondern schrieb die Personen aus einer globalen Variable (die zuvor über einen REST-Service gefüllt wurde) in die DB, löschte dort noch Zeug und lieferte dann das Ergebnis zurück. Der Witz war, dass an der Stelle gar nicht die Personen gelesen sondern in die DB übernommen werden sollten (zumal der globale Mist... anderes Thema).

Wenn Du fremden Code vor Dir hast (oder Du nicht mehr weißt, dass es so und so läuft), dann suchst Du Dich dumm und dusselig - und das nur des Bezeichners der Methode wegen.

Hmm.. nur für mich zum Verständnis: Ich erzeuge doch das Objekt dieser Klasse mithilfe des Konstruktors und soweit mich gelehrt wurde stellt der Konstruktor dann eine Art "State" dar, in der die Klasse erzeugt wird. D.h. aber doch dann, dass die Objekterzeugung stattfindet und dann direkt alle Instanzvariablen erzeugt werden, und DANN erst die Initialisierung über den Konstruktor abläuft, oder?

Genau. Es ist wie @KonradN geschrieben hat: zuerst werden die Instanzvariablen behandelt, dabei findet ggf. eine Standardinitialisierung statt und dann wird der Konstruktor aufgerufen. Dein worker ist zunächst null, dann werden calcDaysOff, calcDaysExtra usw. behandelt und am Ende wird der Konstruktor aufgerufen, der dann erst den worker setzt.

 

[Wuast]

Wundervoll.
Ja ich werde versuchen das zu beherzigen. Ich glaube, da fehlt mir etwas die Praxiserfahrung bei den Bezeichnen. Ich selbst weiß ja immer, was ich meine und kriege dann auch nur Feedback, wenn ich hier was dazu poste.

Ich habe jetzt die Konstruktoren rausgelassen (also gibt nur den Standard-K.) und dann übergebe ich die benötigten Werte über die Getter der Worker-Klasse direkt an die Methoden der facade. Dann funktioniert es auch wie es soll.

 

[KonradN]

Evtl. macht es Sinn, etwas aus den Büchern der Schwarzen Java Magie zu zitieren (JLS und JVMS). Aber da die magischen Sprüche dort weniger interessant sind, versuche ich mich an einer allgemeinverständlichen Erklärung.

Die ganze Magie steckt in einem Zauberwort: new

New ist ein Zauberwort der Java Magier und da steckt extrem viel schwarze Magie hinter - also nicht verzweifeln: Es ist normal, dass Zauberer, die noch nicht Spezialisten der schwarzen Magie sind, da in vielfälltige Probleme rennen.

Wir können einmal erklären, was da für Dämonen herauf beschworen werden und was diese dann so anstellen!

Hinter dem Zauberwort new kommt als erstes immer der Name eines Dämons. In Deinem Fall war es Facade_WorkerDataManamgement. In Klammern kann man dem Dämon, der herauf beschworen werden soll, schon Befehle geben (Bei Dir war es "peter").

So ein Dämon kann aber nicht so einfach erscheinen. Für jeden Dämon muss es ein Dämonenportal geben (im Englischen "Class" genannt). Aber auch so ein Dämonenportal kommt ja nicht einfach so. Für das erscheinen ist der Dämonenportal-Beschwörer da (im Englisch einfach "ClassLoader" genannt).

Wenn Du also jetzt einen Dämon (Englisch: "instance") herbeirufen willst, dann geht das erst einmal an den Dämonenportal-Beschwörer. Der prüft, ob es so ein Dämonenportal schon gibt. Ganz am Anfang wird das noch nicht der Fall sein, daher erstellt er dieses auch als erstes. In der Beschreibung dieser Portale gibt es dann diverse Einstellungen ("class fields" - oft als Klassenvariablen übersetzt was natürlich falsch ist. Es sind Dämonenportal-Einstellungen!) Diese Einstellungen müssen immer einen Wert haben. Also direkt nach dem Entstehen (Magie Unwissende sprechen da von "Speicherbelegung" oder so) werden da also Werte initialisiert. Diese Werte sind entweder "0 Werte" (0, 0.0, null, false) oder ein Wert, der initialisiert werden soll (==> Hier wird also eine Initialisierung stattfinden, die im Code steht!)
Danach kann noch aktiv etwas ablaufen - das sind dann geheime Pergamente - Magie Unkundige nennen es dann oft static initializer. (Das sind dann in der Klasse einfache Codeblöcke). (==> Hier wird dann wirklich richtiger Code ausgeführt!)

Wenn das Dämonenportal erschaffen wurde, dann nutzt der Dämonenportal-Beschwörer dieses, um den Dämon zu beschwören. Dieser hat dann - so wie die Klasse - gewisse Eigenschaften. Diese werden auch bei der Entstehung direkt initialisiert. Das ist 1:1 wie bei dem Dämonenportal. Aso 0-Werte oder eine angegebene Initialisierung. Ist ja auch klar - der Raum, den der Dämon belegt, muss halt erst irgendwie gefüllt werden!
Erst dann kann der Dämon mächte Pergamente lesen - hier spricht der Laie dann von Konstruktoren.

Daher passiert folgendes:

• Zauberer wuast spricht: "new Facade_WorkerDataManamgement(peter);"
• Dämonenportal-Beschwörer: Scheiße, für den Dämon habe ich noch kein Dämonenportal!

--> Beschwört ein Dämonenportal für Facade_WorkerDataManamgement
--> Das Facade_WorkerDataManamgement-Portal initialisiert seinen Raum (Ok, belegt keinen sichtbaren Raum)
--> Das Facade_WorkerDataManamgement-Portal liest seine Pergamente (ok, hat auch keine)
- Dämonenportal-Beschwörer: Ha, jetzt habe ich ein Portal! "Facade_WorkerDataManamgement komm zu mir!"
--> Ein Facade_WorkerDataManamgement Dämon erscheint
--> Der Facade_WorkerDataManamgement Dämon belegt seinen Raum (worker hat keine Initialisierung, daher null, calcDaysOff hat eine Initialisierung und die wird durchgeführt, ...)
--> Der Facade_WorkerDataManamgement Dämon liest ein mächtiges Pergament! Dadurch wird worker auf peter gesetzt. Worker ist damit nicht mehr null!


Ich hoffe, dass dies nun kein zu großer Spoiler war und Du meine Bücher dennoch kaufen und lesen wirst. Java ist halt eine magische Welt - da kommen Harry Potter und Herr der Ringe in keiner Weise mit! Und in meinen Büchern erfährst Du auch was über Drachen und Trolle, die in der Java Language Specification beschrieben sind! Also bleib dran!




Ansonsten hoffe ich, dass diese lustige Schreiberei das, was da etwas abläuft, erläutern konnte.

 

[Wuast]

Ich danke dir, sehr erhellend. Aber nix hier gegen Lotr
Also es läuft immer so ab, dass der Dämon gerufen wird, durch das Portal latscht (sofern vorhanden) und dann erst die Zauberpergamente liest, wodurch er erfährt, dass er z.B. Peter heißt oder mit anderen Dämonen verbunden ist oder was auch immer. Ich bin bis dato davon ausgegangen, dass der Dämon gerufen wird und bevor er durch das Portal kommt eben gebrieft wird, wie er heißt und was er so tun soll (eben durch den Konstruktor). Wie konnte es zu diesem Missverständnis kommen..

Hast du tatsächlich Bücher geschrieben?

 

[KonradN]

Hast du tatsächlich Bücher geschrieben?

Nein, das war nur ein Spaß. Ich bin kein Autor. Habe mal etwas versucht (zu Maven) und habe dann festgestellt, dass es zu aufwändig ist und es mir nicht so sehr liegt. Dann sollte es ein minimales Nachschlagewerk werden aber selbst das war mir zu viel Arbeit. Heraus gekommen sind dann gerade mal zwei GitHub Repositories ... Also Thema Bücher abgehakt

Bei der Problematik: Der Dämon muss aber doch erst in die Welt kommen. Um Pergamente zu lesen muss er ja erst einmal existieren!

Oder um diese Fantasy-Welt zu verlassen: Damit der Konstruktor laufen kann, muss erst der Platz belegt und initialisiert werden. In dem Konstruktor kannst Du ja auf alles Zugreifen. Auch lesend!

Beispiel:

    Facade_WorkerDataManamgement (Worker newWorker){    //hier kommt der Peter an
        System.out.println(this.worker);
        System.out.println(this.calcDaysOff);
        this.worker = newWorker;
    }

Diese Felder gibt es alle, wenn der Konstruktor läuft. Das heisst, diese Werte sind initialisiert worden.
Und das sind entweder diese "0-Werte" oder eben die Initialisierung, die mit = angegeben wurde.

Daher läuft diese Initialisierung zuerst und erst dann der Konstruktor.

 

[Wuast]

Macht alles Sinn für mich! Auch eine tolle Metaphorik mit der Dämonenbeschwörung. Ich denke (hoffe), das bleibt im Kopf.

 

[mihe7]

New ist ein Zauberwort der Java Magier und da steckt extrem viel schwarze Magie hinter

Ah, @KonradN, der dunkle Lord des Java-Reichs. Jetzt weiß ich erst, warum ich den ganzen Tag in der Kammer des Schreckens verbringen muss...