[java] fout met array in methode

[Verwijderd]

Er is een 2D-array die wordt aangemaakt in een externe klasse waarvan de grootte bepaald wordt door het resultaat van een SQL-Query.

In de klasse waar deze methode staat is het array zonder problemen beschikbaar, maar ik heb nu deze methode gemaakt om hem vanuit een andere klasse aan te roepen, maar hier geeft hij een fout nullpoint exeption.

het makkelijkst is natuurlijk om het 2d array meteen aan te maken en met onzin te vullen om een nullpoint exeption te voorkomen maar dat kan niet omdat dan de groote later niet meer kan worden gewijzigd als deze anders is dan het resultaat van de sql query

hieronder staat de methode:

code:

    public String geefZoekResult(int x ,int y){ 
        
        String result1 = "" + zoekresult[x][y];
        //System.out.print("" + result1);
        return result1 ;
    }

[Rigi]

euhm, wat dacht je ervan om er een wait notify constructie van te maken
laat de klasse waarin de aanroep staat checken of er iets in staat, zo niet doe wait(); en laat de owner een notify(); doen als de array gevuld is

[riezebosch]

bijhouden in die class wat de maximale x en y zijn? en dan in de geefZoekResult een if-je of het gevraagde resultaat wel binnen het bereik ligt

[Verwijderd]

Hij geeft de foutmelding niet bij het gebruiken van de methode, maar bij het initialiseren van de methode.

[Glimi]

Kortom de inhoud van de array is op het punt van het vragen null en kan dus niet derefferenced worden.
Waarom doe je dan niet gewoon een nullcheck?

Wat staat er eigenlijk verder in dat zoekResult, want kun je daar niet beter een object van maken, zodat je rows, cols ed. kan fetchen?

riezebosch schreef op 03 April 2003 @ 14:26:
bijhouden in die class wat de maximale x en y zijn? en dan in de geefZoekResult een if-je of het gevraagde resultaat wel binnen het bereik ligt

Nou ik denk dat dat eerder een ArrayOutOfBoundsException is

[ Voor 36% gewijzigd door Glimi op 03-04-2003 14:32 ]

[Janoz]

Wat versta je onder het 'initialiseren' van een methode?

[Verwijderd]

Met initialiseren bedoel in het starten (builden) van de applicatie...

maar ik denk dat ik het niet helemaal duidelijk heb omschreven.

in klasse a heb ik de bovengenoemde methode staan. en de tekstvelden om een sql query mee uit te voern

in klasse b wordt het array gevult aan de hand van gegevens die via de sql query in een array gezet worden.

in klasse c wil ik deze resultaten zien

zoals bekend moet ik dan in klasse a een methode schrijven die vanuit klasse c aangeroepen dient te worden

bij het builden van de applicatie krijg ik een foutmelding "null pointer exeption" dit is aan de ene kant wel begrijpelijk omdat op hetr moment dat de methoden "gebuild" wordt de groote en de inhoud van de array nog onbekend zijn.

Weet iemand een oplossing?

[VinnieM]

Waarschijnlijk wordt dus die methode 'geefZoekResult' al aangeroepen terwijl er nog geen array is (hij is null). Zet dus gewoon een simpele null-check om de operatie (zoals iemand anders al aangaf):

code:

public String geefZoekResult(int x ,int y){ 
    String result = "";
    if (zoekresult != null) {
        result = "" + zoekresult[x][y];
        //System.out.print("" + result);
    }
    return result;
}

[.oisyn]

geef je hele code is, want ik begrijp er nog weinig van (PS. met builden wordt over het algemeen het compilen bedoeld)

Maar heb je de array van tevoren wel gealloceerd?

[Verwijderd]

het probleem is inmiddels opgelost bedankt

[Soultaker]

Verwijderd schreef op 03 April 2003 @ 17:51:
het probleem is inmiddels opgelost bedankt

Wil je voortaan even van te voren een bewuste keuze maken om ofwel je probleem zelf op te lossen, ofwel het hier op GoT te presenteren met duidelijke uitleg en de uiteindelijke oplossing?

Dit komt een beetje ondankbaar over tegenover de mensen die ondanks je slechte opening post de moeite hebben genomen te proberen je probleem te begrijpen en je te helpen het op te lossen. Je doet het nu af met "bedankt", maar een beschrijving met wat de bedoeling was en hoe je het nu opgelost hebt, blijft achterwege. Dat is niet echt bevredigend voor de mensen die interesse in het probleem toonden.

[Verwijderd]

Het was opgelost met de code van VinnieM. Dat was dus de oplossing. En dus bedankt. Ook bedankt naar alle anderen die hebben meegedacht .
_{ik werk dus samen met Jlo2003}

[ Voor 25% gewijzigd door Verwijderd op 04-04-2003 11:28 ]

[Janoz]

Dat noem ik geen oplossing, maar symptoom bestrijding. Die nullpointer exception geeft mij meer het idee dat er heel wat mis is met het ontwerp. Waarschijnlijk zal een flow diagram wonderen doen.

[Alarmnummer]

Het probeem zit hem bij lege array en null. Null waardes zijn altijd erg vervelend (en naar mijn mening zwaar overgewardeerd). Er zou minimaal een lege array beschikbaar moeten zijn, zodat je niet iedere keer op null hoeft te checken.

Ik ben er zelf voor om de nullwaardes volledig uit de verzameling van reference waardes te halen.

zie http://nice.sourceforge.net

3.2. Null pointers (NullPointerException)

In current imperative languages, references (or pointers) can hold a special value meaning "reference to nothing". This value is called null in Java, NULL in C and C++. At run time, however, dereferencing this value results to a runtime error (NullPointerException) or a run time crash (bus error, segmentation fault, protection fault, ...).

To prevent this error, a reference must be tested before use. However it is easy to forget to do so. Furthermore, there are references that are never null, or rather that should never be. Testing such references clutters the code. Every variable should therefore be documented as being possibly null or not. Every method should document whether each of its argument can be null or not, and whether it can return a null result. But then remains the task of checking that the code indeed is correct and indeed conforms to the documentation. Correctness requires for instance that if a variable is possibly null, it should always be tested before dereferencing. It also requires to match arguments of a method to its documented behavior regarding null arguments. All these checks are rather simple but very tedious. The situation is even much worse when code evolves: this checking must be done all over again.

Here obviously comes our motto: all this checking should be done automatically. This is exactly what Nice does. One documents whether a type can hold the null value by simply prefixing it with the '?' symbol. Thus: ?String name; is the declaration of String variable that might be null. To get its length, one must write int len = (name == null) ? 0 : name.length();. Calling name.length() directly is a type error. It would only be possible if name was defined as String name = "Some non-null string";.

Je kunt dus nu compiletime dit soort problemen al aanpakken.

[ Voor 3% gewijzigd door Alarmnummer op 04-04-2003 12:42 ]

[Verwijderd]

Ik vind null juist heel handig. Zeker bij methodes waar elke return mogelijk is en je toch aan wilt geven dat er iets mis is, bijvoorbeeld getProperty( String key ). Om hier nou een Exceptie te gooien is zwaar overdreven, en een lege string zou best wel eens de waarde van een property kunnen zijn. Oftewel null is een mooie manier om aan te geven dat de property niet bestaat.

[.oisyn]

Het gaat er ook meer om dat een variabele null kan zijn dan dat de returnwaarde van een functie null kan zijn

[Alarmnummer]

Verwijderd schreef op 04 April 2003 @ 12:51:
Ik vind null juist heel handig. Zeker bij methodes waar elke return mogelijk is en je toch aan wilt geven dat er iets mis is, bijvoorbeeld getProperty( String key ). Om hier nou een Exceptie te gooien is zwaar overdreven, en een lege string zou best wel eens de waarde van een property kunnen zijn. Oftewel null is een mooie manier om aan te geven dat de property niet bestaat.

Dan kan je ook zeggen:

public Object? getProperty(String key){...}

Hierdoor kan je zien dat getProperty of een null terug stuurt, of een Object. Als jij dan als volgt gaat aanroepen:

Object item = getProperty("foo");

Dan krijg je een compiletime foutmelding omdat item alleen niet null waardes aankan, en die getProperty stuurt eventueel wel een null terug. Er gaat dus niets verloren, er komt zelfs type-functionaliteit bij.

[ Voor 3% gewijzigd door Alarmnummer op 04-04-2003 12:57 ]

[Janoz]

Wat zou er mis kunnen gaan bij het opvragen van een property? En waarom zou dat niet met een exceptie aangegeven kunnen worden?

[Verwijderd]

als de property niet bestaat, wat in compile time niet duidelijk is bijvoorbeeld, zou er iets mis kunnen gaan. Daar ga ik geen dure exceptie handling voor gebruiken, maar domweg null returnen. en die null stop je in een variabele en ergens anders controleer je hem weer op null (als tenminste de mogelijkheid bestaat dat een methode null returned)

[Janoz]

Owh, ok. Ik was in de veronderstelling dat hij alleen null terug kon geven waneer er wat fout was gegaan bij het opvragen van de propperty. Als je van te voren opgeeft dat iets null kan zijn is het een iets ander verhaal, maar dat zegt alarmnummer ook al .

[misfire]

In Nice zijn dit soort dingen inderdaad illegaal tenzij je specifiek aangeeft dat je een null waarde _wil_, en dan _moet_ je testen bij een aanroep. Je kunt trouwens nog steeds een IndexOutOfBoundsException krijgen met de "oplossing" van Vinnie. Ik zou als ik jou was eens kijken hoe je het voor elkaar krijgt dat je deze methode aanroept zonder dat je blijkbaar de lengtes van de array test of hoe het komt dat deze array null is. Welke taal je ook gebruikt, uiteindelijk is het altijd beter dat je zelf goed nadenkt over je code dan dat je net zo lang compiler errors en runtime exceptions oplost totdat het werkt.