[JAVA] java.lang.NullPointerException bij uitlezen object

[KillerZero86]

Ik heb een main class die een machine class aanstuurt, die vult classes chip en doos.
Chip:

Java:

public class Chip {

    int nummer, volgNummer;
    String type, adres;

    public Chip(String _type, int id, String adres, int volgNummer) {
       nummer = id;
       type = _type;
       this.adres = adres;
       this.volgNummer = volgNummer;
    }
   
    public void printChip() {
        System.out.println(nummer);
        System.out.println(type);
        System.out.println(volgNummer);
    }

}

Doos:

Java:

public class Doos {
    private String adres;
    public Chip c, c1;
    public void setAdres(String adres){
     this.adres = adres;
    }
    public void pakIn(Chip c){
        this.c = c;
    }
    public void printDoos() {
        System.out.println(adres);
        c.printChip();
        }
}

Probleem:
De main doet 3 keer hetzelfde en iedere keer wordt de doos met de "gevulde" chip in array dozen (van het type Doos) gestopt. Maar als ik uit wil lezen gaat het grondig fout. Ik kan de adressen die op de doos opgeslagen staan uitlezen, maar zodra ik de chip (die ook in de doos is geimporteerd) wil gaan uitlezen krijg ik de volgende error:

code:

Exception in thread "main" java.lang.NullPointerException
        at Doos.printDoos(Doos.java:19)
        at Application.main(Application.java:16)
Java Result: 1

Op regel 16 van de main staat trouwens:

Java:

dozen[1].printDoos();

Wat gaat er fout en hoe is het op te lossen?

[CoolGamer]

Op regel 19 van Doos.java staat een aanroep van een variabele die nog null is. Je zou de variabele kunnen instellen of je zou kunnen checken met een if of de variabele al geset is.

Dit is overigens wel een heel simpele vraag. Als je even zoekt op de error kan je er zat over vinden.

[DEiE]

En ik schat dat dat de string "adres" is . Klopt het dat je de setAdres-functie nog niet hebt aangeroepen?

[Domdo]

Ik weet niet of je er al aan gedacht had, maar misschien is het eventueel een optie om er stap-voor-stap door heen te lopen met een debugger.

[CoolGamer]

Domdo schreef op zaterdag 04 december 2010 @ 17:44:
Ik weet niet of je er al aan gedacht had, maar misschien is het eventueel een optie om er stap-voor-stap door heen te lopen met een debugger.

Die methode is zeker aan te bevelen. Zeker als je net begint met programmeren is het handig als je goed leert gebruik te maken van de debugger. Maakt het opsporen van problemen een stuk makkelijker.

Al staat in de error-message wel het regelnummer vermeld waar het mis gaat, dus daar zou je ook vanuit kunnen gaan.

[Sebazzz]

Ik spot een programmeeropdracht van jaar 1 informatica HRO

Zoals gezegd, plaats een breakpoint en kijk wat null is

[Remus]

TheCoolGamer schreef op zaterdag 04 december 2010 @ 17:39:
Op regel 19 van Doos.java staat een aanroep van een variabele die nog null is. Je zou de variabele kunnen instellen of je zou kunnen checken met een if of de variabele al geset is.

Dit is overigens wel een heel simpele vraag. Als je even zoekt op de error kan je er zat over vinden.

Nope, System.out.println zal gewoon "null" printen als adres nog null is. System.out.println(String) gebruikt namelijk Object.toString(param) een null check waarbij expliciet "null" wordt geprint, of bij System.out.println(Object) String.valueOf(Object) wat ook expliciet "null" geeft indien het object null is.

Dat betekent wel dat er nog maar een optie over is

[ Voor 12% gewijzigd door Remus op 04-12-2010 18:23 ]

[KillerZero86]

regel 19 hoort regel 12 te zijn en verwijst dus naar printChip(). Maar zelfs als ik deze leeghaal duikt deze error op, dus het vullen van adres heeft er niets mee te maken.

@theCoolGamer: de uitleg mag dan makkelijk te vinden zijn, het blijft een hele vage error. Praktisch gezien zegt hij dat er iets aan de hand is met het commando dat op die gegeven regels wordt uitgevoerd.

[HuHu]

Dan is c dus null.

[KillerZero86]

Hoe kan dat? Heel doos wordt in een array gezet en in de class doos wordt duidelijk chip c geimporteerd?

[Haan]

KillerZero86 schreef op zaterdag 04 december 2010 @ 18:39:
@theCoolGamer: de uitleg mag dan makkelijk te vinden zijn, het blijft een hele vage error. Praktisch gezien zegt hij dat er iets aan de hand is met het commando dat op die gegeven regels wordt uitgevoerd.

Het is helemaal geen vage error, je krijgt precies te zien wat er fout gaat. Maar zoals gezegd, ga gewoon debuggen en regel-voor-regel door het programma lopen, dan zie je vanzelf wat er fout gaat. Zie ook Programming FAQ - Algemeen

[HuHu]

Jij gaat het niet ver schoppen met je Informatica-studie.

Roep je pakIn wel aan? Zo nee, wat voor waarde heeft c dan? Juist... null.

[PSP123]

De reden van de fout: java.lang.NullPointerException, is dat je een methode uitvoert op een null. Oftewel geen object.
Afgelopen maandag deze error in ons college gehad.

By the way, rottige error ben er zelf ook al een paar keer tegen aan gelopen!

[KillerZero86]

Speel je t nou op de man? Wat mag pakln wel niet zijn?

De error is trowuens betrekkelijk ernstiger: als ik system.out.println(c.nummer); geef komt precies dezelfde error. Als c null is moet er dan null geprint worden, omdat alle waarden in c gelijk zijn aan null. Maar er wordt geen null geprint..

[Haan]

KillerZero86 schreef op zaterdag 04 december 2010 @ 18:51:
Speel je t nou op de man? Wat mag pakln wel niet zijn?

Een functie in je eigen class

De error is trowuens betrekkelijk ernstiger: als ik system.out.println(c.nummer); geef komt precies dezelfde error. Als c null is moet er dan null geprint worden, omdat alle waarden in c gelijk zijn aan null. Maar er wordt geen null geprint..

Nee, als c null is, en je probeert iets aan te roepen in c, krijg je een... nullpointerexception. Misschien goed om even terug in het studieboek te duiken

[KillerZero86]

Ik heb het probleem, maar dat betekend niet dat ik er iets van snap.

Er was een extra methode genaamd pakUit(), in doos. Deze was gemaakt om de chip op null te zetten (wat moet om een vage reden). Er was een methode in machine die deze methode aansprak, maar er werd vanuit de main nergens om deze methode gevraagd, deze methode werd dus tijdens het draaien niet uitgevoerd. Als het goed is. Want dat gebeurde wel, en wel na het toevoegen van c aan Doos, maar voor het plaatsen van doos in array. Van vaagheden gesproken. Nadat ik de beide methodes had omgetoverd in comments draait het programma feilloos.

Overigens dacht ik dat de hoofdletter i een l was en las ik eht dus als pakLn. Mijn excuses.

[Herko_ter_Horst]

Dus jouw oplossing voor het probleem is code uitcommenten en dan zeggen dat het werkt? Zo kan ik het ook: gewoon alle code weggooien, heb je zeker geen fouten meer.

In plaats van dat je nou probeert te begrijpen wat er gebeurt... Zeker in zo'n eenvoudig programma is het makkelijk genoeg - zelfs als je geen debugger hebt of weet te gebruiken - om stap voor stap het programma door te lopen (gewoon met een vingertje bij de regels op het scherm) en te kijken wat er gebeurt.

In dit geval is de waarde van het veld c gelijk aan null op het moment dat je printDoos() aanroept. Dat betekent dat c niet naar een object wijst, maar naar 'niets'. Op 'niets' kun je geen methoden aanroepen, dus krijg je een NullPointerException.

Uit de code die je hebt gepost, blijkt dat je eerst de method Doos.pakIn() moet aanroepen om c een waarde te geven. Dat c null is betekent:

• dat je dat niet gedaan hebt, óf
• dat je dat wel gedaan hebt, maar met een parameter die null was, óf
• dat je tussen het aanroepen van pakIn() en het aanroepen van printDoos() iets anders gedaan hebt waardoor c weer null geworden is. Blijkbaar doet pakUit() dat.

Het kan dus best zijn dat printDoos() rekening moet houden met het feit dat c wel eens null kan zijn. In dat geval mag je geen methoden op c aanroepen, maar moet je iets anders doen. Om dit te regelen, gebruik je dan een if-statement.

Een computer doet PRECIES wat jij hem opdraagt, en dat is niet altijd wat je bedoelt. Alle vaagheid komt van jouw kant. Loop je programma dus stap voor stap na.

[Remus]

KillerZero86 schreef op zaterdag 04 december 2010 @ 18:51:
Speel je t nou op de man? Wat mag pakln wel niet zijn?

De error is trowuens betrekkelijk ernstiger: als ik system.out.println(c.nummer); geef komt precies dezelfde error. Als c null is moet er dan null geprint worden, omdat alle waarden in c gelijk zijn aan null. Maar er wordt geen null geprint..

Nee, want als je c.nummer doet, dan heb je een geldig object nodig in c om het veld nummer op te vragen. Als c echter null is dan heb je geen object en dus leidt dat (het dereferencen van de variabele c) tot een NullPointerException.

Dit is echt een zeer basaal iets van programmertalen zoals Java, en ik zou maar snel onder de knie krijgen 1) hoe je dit soort problemen analyseert en 2) hoe je dit soort problemen of voorkomt of ondervangt.

[KillerZero86]

Herko_ter_Horst schreef op zaterdag 04 december 2010 @ 19:45:
[...]

I did. Er staat een methode in die wordt uitgeoverd zonder dat ik dat vraag. En ja, dat vindt ik vaag. Zou aan netBeans kunnen liggen, ga morgen nog wel even met de normale javac compiler proberen.

Er bestaat trouwens een zeker verschil tussen het uitcommenten van 2 ongebruikte methodes (samen 6 regels) en het wissen van al je code. Je stelt je tochw el een klein beetje aan, je moet toch toegeven dat het vrij vaag is als een class die niet eens kan starten (en nee hij wordt ook niet ergens anders gestart, dan zou het compilen falen) je hele code weet te saboteren.

[ Voor 36% gewijzigd door KillerZero86 op 04-12-2010 20:13 ]

[Herko_ter_Horst]

Hoe heb je gecontroleerd dat die bepaalde methode wordt aangeroepen?

Ik kan je verzekeren dat als die methode inderdaad aangeroepen wordt, je dat toch echt zelf ergens hebt geprogrammeerd. Dat ligt niet aan Netbeans. Zoals gezegd: computers doen precies wat mensen ze opdragen. Dat dat niet altijd is wat die mens bedoelde te vragen, is de fout van de mens, niet van de computer.

Misschien is het handig om toch even al je code te posten, liefst met regelnummers die overeenkomen met de foutmelding die je krijgt.

[ Voor 18% gewijzigd door Herko_ter_Horst op 04-12-2010 20:30 ]

[Anoniem: 145681]

By the way, rottige error ben er zelf ook al een paar keer tegen aan gelopen!

Rottig ? Het moet zowat de eenvoudigste Java error zijn om te fixen.
Als het al niet obvious is wat er null is op die regel een breakpoint, kijken met de debugger wat er null is en het fixen.

En als je niet weet waarom een field null is, gewoon een breakpoint op de field zetten en zien wie hem allemaal wijzigt.

Vage errors, Netbeans doet vaag, Java voert methods uit die ik nooit oproep

[Remus]

KillerZero86 schreef op zaterdag 04 december 2010 @ 20:05:
[...]

I did. Er staat een methode in die wordt uitgeoverd zonder dat ik dat vraag. En ja, dat vindt ik vaag. Zou aan netBeans kunnen liggen, ga morgen nog wel even met de normale javac compiler proberen.

Grote onzin. Over het algemeen moet je dit soort bugs niet aan een compiler of IDE toekennen, want bijna altijd is het de programmeur die de fout maakt, zijn eigen code niet goed begrijpt of de werking van de programmeertaal niet onder de knie heeft. Dit soort fouten verwijten aan de compiler is een zwaktebod, en zal je op geen enkele manier helpen het probleem te vinden.

Er bestaat trouwens een zeker verschil tussen het uitcommenten van 2 ongebruikte methodes (samen 6 regels) en het wissen van al je code. Je stelt je tochw el een klein beetje aan, je moet toch toegeven dat het vrij vaag is als een class die niet eens kan starten (en nee hij wordt ook niet ergens anders gestart, dan zou het compilen falen) je hele code weet te saboteren.

Jij bent de diegene die zich aanstelt. Jij doet iets fout in je code, jij bent degene die zijn fout moet opzoeken. Wij geven alleen maar tips hoe je het kan opzoeken, en geven commentaar op opmerkingen van je die kant noch wal raken.

Ga debuggen, loop stap voor stap door je code heen, zet breakpoints aan het begin van de methode die volgens jou niet uitgevoerd hoort te worden, en kijk aan de hand van de stacktrace waar die wordt aangeroepen.

[Maniacs]

KillerZero86 schreef op zaterdag 04 december 2010 @ 18:43:
Hoe kan dat? Heel doos wordt in een array gezet en in de class doos wordt duidelijk chip c geimporteerd?

Hier beschrijf je je denkfout. Waar vermoed jij dat Chip c geset wordt? Dat gebeurd namelijk nergens in de door jou gepostte code. Mocht je denken dat dat op regel 8 (in je code voorbeeld) van Doos.java plaatsvind, dan haal je de begrippen class en object door elkaar.

Verder is een stacktrace in geval van NullPointerExceptions ontzettend handig, aangezien hij precies verteld op welke regel in de code jou fout zit. Een makkelijker te traceren programmeerfout is er bijna niet:
In jou geval vindt er een nullpointer plaats op regel 19 van Doos.java. Dit is de hoogste regel in je stacktrace, dus de oorzaak van het geheel. Er zit dus geen fout in de methode printChip() anders zou de stacktrace daarheen verwijzen.
Blijft er nogmaar 1 oorzaak over die hier al een paar keer genoemd is.

Trouwens, c en c1 zijn public gedeclareerd. Het is handiger om hier private van te maken zodat ze enkel door Doos instanties te benaderen zijn. Dit voorkomt bijvoorbeeld NullPointerExceptions

[KillerZero86]

Jullie geven me niet alleen tips, jullie vallen me onder andere ook persoonlijk aan. Maar zoals ik al zei: de error is weg en de code doet nu precies wat hij behoort te doen.

[Hydra]

KillerZero86 schreef op zondag 05 december 2010 @ 13:50:
Jullie geven me niet alleen tips, jullie vallen me onder andere ook persoonlijk aan. Maar zoals ik al zei: de error is weg en de code doet nu precies wat hij behoort te doen.

Je bent duidelijk nog erg jong. Dat is geen aanvallen, dat heet kritiek, die in deze compleet terecht is. Ik heb ook in die fase ("what de fuck is een NPE?") gezeten, maar na een tijdje zijn dat fouten die je niet meer maakt (nouja, als je 'em maakt snap je meteen wat je fout gedaan hebt) omdat je het probleem begrijpt.

Wat jij doet is een manier van fouten voorkomen die heel veel eerstejaars doen: ze begrijpen het niet, en verwijderen dus dan maar de regel waat het fout gaat, of doen het op een andere manier waarop het toevallig wel goed gaat, zonder te begrijpen waarom het fout gaat. En dat is geen optie, de mensen die aan die methode vast zijn blijven houden vielen na hun eerste of 2e java-vak af.

Het is heel simpel: als je een object referentie hebt waar nog geen instantie op aangemaakt is ("Object c" is slechts een lege referentie, "Object c = new Object();" is een referentie naar een instantie), en daarvan een functie of een membervariabele probeert te benaderen (dus "c.eenVar" of "c.toString();") krijg je hoe dan ook een exception omdat het "Object c" nog niet bestaat, het enige wat je hebt is een lege referentie, oftewel een "null pointer".

Dit MOET je snappen, anders ga je grandioos in de problemen te komen. De reden dat mensen wat geirriteerd reageren is omdat dit basiskennis is en je niet je best doet het te snappen.

[Anoniem: 187672]

@Hydra
Hij wordt wel degelijk aangevallen

Jij gaat het niet ver schoppen met je Informatica-studie.

Wat hierboven staat is gewoon een directe aanval en niks anders. Iedereen heeft het moeten leren en daarom is dit heel erg flauw om op deze manier te zeggen.

[Haan]

Anoniem: 187672 schreef op maandag 06 december 2010 @ 12:01:
@Hydra
Hij wordt wel degelijk aangevallen

[...]

Wat hierboven staat is gewoon een directe aanval en niks anders. Iedereen heeft het moeten leren en daarom is dit heel erg flauw om op deze manier te zeggen.

Dat is de enige opmerking die echt op de man speelt, de rest is gewoon kritiek, misschien soms wat hard, maar dat heeft de TS ook deels aan zichzelf te danken. Beginner zijn is niet erg, dat zijn we tenslotte allemaal (geweest ), maar als je dan met een probleem hier komt, is het wel zo netjes om ook wat te doen met alle tips die worden gegeven. Ik vind dat Hydra het heel goed verwoord

[Creepy]

Even los van het feit dat dit eigenlijk iets is wat zelf opgelost zou moeten kunnen worden: Er wordt hier echt teveel op de man gespeeld en dat gaat net even te ver. Ik hoop er aantal mensen hier zijn die zelf kunnen inschatten dat ze ook tever zijn gegaan en dat simpelweg in de toekomst niet meer doen. Je antwoord op een normale manier, of je negeert het topic.

Ik denk dat KillerZero86 genoeg informatie heeft om op dit moment verder te kunnen. Zo niet, dan kan je een nieuw topic openen maar let daarbij aub wel op Het algemeen beleid #quickstart.