[Java] ArrayList geeft exceptions waar het niet zou mogen

[Verwijderd]

Ik ben bezig met een programma dat gebruik maakt van de ArrayList klasse, maar na een paar lange testen bleek deze af en toe een IndexOutOfBoundsException te geven, terwijl het stukje code waarin hij dan zit niet outofbounds kan gaan.

De code waar het om gaat:

code:

for(int index=0;index<list.size();index++){
    list.set(index, ((String)list.get(index)).toLowerCase());
}

Hij is ook niet consistent met het genereren van deze exceptions, de eerste keer gaf hij na 2000 records deze exception, de 2e keer na 370 records en nu draait hij weer gewoon door net als gisteren (gisteren 19000 zonder exception, en nu heeft hij er 750 gehad zonder 1 probleem).

Heeft iemand enig idee wat dit zou kunnen zijn?

Mja, een ArrayList is niet synchronized, maar ik gebruik dan ook geen threads (Op die ene thread die ik van java.exe krijg als ik de applicatie start na dan.) Of zie ik nou iets over het hoofd mbt. Threads?

Mvg,
Alex

[Glimi]

• Dit stukje code kan voor geen problemen zorgen, behalve als de lijst gewijzigd wordt, tijdens het draaien van de loop
• Events worden in de EventDispatch Thread gekwakt. Wijzig je soms in events iets aan deze list?

[bigben04]

Ik sluit me bij Glimi aan. Er wordt blijkbaar toch echt buiten dit stukje code iets aan de arraylist aangepast. Dit moet dan wel in een event zijn.

[Verwijderd]

Glimi schreef op 12 december 2003 @ 13:09:
• Dit stukje code kan voor geen problemen zorgen, behalve als de lijst gewijzigd wordt, tijdens het draaien van de loop
• Events worden in de EventDispatch Thread gekwakt. Wijzig je soms in events iets aan deze list?

Alleen het element in de lijst wordt uitgelezen en bewerkt tijdens het draaien van de loop... Er worden geen elementen toegevoegd / verwijderd (de functie die in de loop aangeroepen wordt krijgt alleen de uitgelezen string mee)

Events doe ik ook niks mee, ik maak gewoon een standaard ArrayList aan, en voeg met .add() dingen toe. Er worden geen elementen verwijderd, alleen toegevoegd, maar dat gebeurt dus in een ander stuk code dat door deze exception niet eens bereikt wordt (hij moet eerst de loop afmaken)

[Verwijderd]

bigben04 schreef op 12 december 2003 @ 13:23:
Ik sluit me bij Glimi aan. Er wordt blijkbaar toch echt buiten dit stukje code iets aan de arraylist aangepast. Dit moet dan wel in een event zijn.

Het is een console-applicatie, en gebruikt helemaal geen events. (Tenminste, er zijn geen event-handlers gedefinieerd)

[ Voor 8% gewijzigd door Verwijderd op 12-12-2003 13:25 ]

[bigben04]

Misschien zit er een (null) string (o.i.d., iig een niet-geinitialiseerde string) in je lijst waardoor 'ie faalt op de .toLowerCase()?

[ Voor 24% gewijzigd door bigben04 op 12-12-2003 13:27 ]

[Verwijderd]

bigben04 schreef op 12 december 2003 @ 13:26:
Misschien zit er een (null) string (o.i.d., iig een niet-geinitialiseerde string) in je lijst waardoor 'ie faalt op de .toLowerCase()?

Zou kunnen, maar dan zou java een nullpointerexception gooien toch?

Ik moet wel even vermelden denk ik dat dat .toLowerCase() een voorbeeld is, in de echte code wordt een eigen functie over die string heen gehaald die eerst kijkt of het null, "" of iets bruikbaars is.

Deze functie retourneert dan de bewerkte string, of een nieuwe lege string ( "" )

[ Voor 36% gewijzigd door Verwijderd op 12-12-2003 13:32 ]

[bigben04]

Verwijderd schreef op 12 december 2003 @ 13:28:
[...]
Zou kunnen, maar dan zou java een nullpointerexception gooien toch?

Ja, das waar ja, haal ff 2 exceptions door elkaar.

Misschien kan je proberen om in elke iteratie (of eens in de x keer) de list.size() laten afdrukken zodat je kan zien of er idd vreemde dingen met die size gebeuren.

[Verwijderd]

bigben04 schreef op 12 december 2003 @ 13:32:
[...]

Ja, das waar ja, haal ff 2 exceptions door elkaar.

Misschien kan je proberen om in elke iteratie (of eens in de x keer) de list.size() laten afdrukken zodat je kan zien of er idd vreemde dingen met die size gebeuren.

Probeer ik ook, maar tot nu toe heb ik de exception niet weer gekregen (de code is wel hetzelfde) en krijg ik elke keer netjes de grootte van de lijst en het aantal iteraties op die lijst terug. Deze waardes kloppen wel elke keer...


(Edit01: waarden->waardes)

[ Voor 3% gewijzigd door Verwijderd op 12-12-2003 13:35 ]

[Verwijderd]

Is het mogelijk dat de ArrayList heel soms ipv. het aantal elementen de totale ruimte binnen de array teruggeeft?

Bij de indexoutofbounds exception stond namelijk altijd een waarde 10, en dit is ook de standaard initiele capacity van een ArrayList.

[Alarmnummer]

Verwijderd schreef op 12 december 2003 @ 13:49:
Is het mogelijk dat de ArrayList heel soms ipv. het aantal elementen de totale ruimte binnen de array teruggeeft?

Als jij size opvraagt geeft de array list (gelukkig) het aantal echte elementen in je lijst terug. Niet de huidige size van de array.

[Robtimus]

Verwijderd schreef op 12 december 2003 @ 13:49:
Is het mogelijk dat de ArrayList heel soms ipv. het aantal elementen de totale ruimte binnen de array teruggeeft?

Bij de indexoutofbounds exception stond namelijk altijd een waarde 10, en dit is ook de standaard initiele capacity van een ArrayList.

Nee, daar is de capacity voor, niet de size. Size is echt het aantal elementen in de List, niet hoeveel er eventueel in zouden kunnen.

Mijn afstudeerbegeleider maakte die fout eens. Mocht ik hem verbeteren

/Edit: de capacity() method zit niet in ArrayList, wel in Vector. Maar hij gebruikte dan ook Vectoren (ook in declaratie )

[ Voor 11% gewijzigd door Robtimus op 12-12-2003 13:55 ]

[drm]

Waarom werk je niet gewoon met een Iterator of een ListIterator, eigenlijk

[Verwijderd]

IceManX schreef op 12 december 2003 @ 13:54:
[...]
Nee, daar is de capacity voor, niet de size. Size is echt het aantal elementen in de List, niet hoeveel er eventueel in zouden kunnen.

Mijn afstudeerbegeleider maakte die fout eens. Mocht ik hem verbeteren

/Edit: de capacity() method zit niet in ArrayList, wel in Vector. Maar hij gebruikte dan ook Vectoren (ook in declaratie )

yupz, daarom vind ik het ook zo vreemd dat een lus als

while(index<list.size()) {index++;}

indexoutofbounds exceptions geeft.

Uitgaande van de correcte werkingvan size() zou je die error nooit moeten kunnen triggeren (tenzij je de lijst gaat vergroten/verkleinen natuurlijk binnen de lus).

Maar toch krijg ik op onvoorspelbare momenten een 'IndexOutOfBounds 10' voor me kiezen, wat me dan laat twijfelen aan de werking van size() aangezien de default-capacity van een ArrayList 10 is.

(Edit01: quote toegevoegd)

[ Voor 34% gewijzigd door Verwijderd op 12-12-2003 14:02 ]

[Verwijderd]

drm schreef op 12 december 2003 @ 13:55:
Waarom werk je niet gewoon met een Iterator of een ListIterator, eigenlijk

Zou ook kunnen ja, maar ik maak liever zo min mogelijk objecten aan. En aangezien ArrayList de functies get,set,size en add heeft dacht ik dat het aanmaken van een iterator overbodig zou zijn.

[machiel]

Welke JDK gebruik je? Er is een kleine kans dat het een VM-fout is

[drm]

Euhm, maar dit is precies waar die iterators voor zijn gemaakt; iteratief door collections heenwandelen. Ik zou niet weten waarom je het dan ook niet daarvoor zou gebruiken...

[Verwijderd]

mickgreen schreef op 12 december 2003 @ 14:08:
Welke JDK gebruik je? Er is een kleine kans dat het een VM-fout is

1.4.1_02

[Verwijderd]

drm schreef op 12 december 2003 @ 14:08:
Euhm, maar dit is precies waar die iterators voor zijn gemaakt; iteratief door collections heenwandelen. Ik zou niet weten waarom je het dan ook niet daarvoor zou gebruiken...

Tja, daar kan je over twisten. Iterators zijn daarvoor gebouwd, maar een list heeft zelf alle functies die je nodig hebt om door een lijst te fietsen. Dus je kan een iterator aanmaken en dan door die iterator gaan fietsen, of direkt door de lijst. Mij lijkt het laatste dan efficiënter. Het zou zowieso niks uit mogen maken qua uiteindelijke resultaat lijkt me.

(Edit01: text toegevoegd)

[ Voor 10% gewijzigd door Verwijderd op 12-12-2003 14:17 ]

[curry684]

Verwijderd schreef op 12 december 2003 @ 14:15:
[...]
Dus je kan een iterator aanmaken en dan door die iterator gaan fietsen, of direkt door de lijst. Mij lijkt het laatste dan efficiënter.

Foute aanname Iterators nemen niet meer ruimte of CPU-tijd in dan jouw custom-iteratieroutine, en zijn uitgeoptimaliseerd voor het laatste procentje performance. Ze zijn dus met 99% zekerheid zuiniger met geheugen en clockcycles dan jou hobby-versie.

[ Voor 15% gewijzigd door curry684 op 12-12-2003 14:18 . Reden: duh verkeerde quote dankzij edit ]

[Glimi]

Heb je anders wat meer code, die de foutmelding geeft? Als het veel is evt in een zipje oid, maar dan kan ik er even mee aan de slag.

[Verwijderd]

curry684 schreef op 12 december 2003 @ 14:18:
[...]

Foute aanname Iterators nemen niet meer ruimte of CPU-tijd in dan jouw custom-iteratieroutine, en zijn uitgeoptimaliseerd voor het laatste procentje performance. Ze zijn dus met 99% zekerheid zuiniger met geheugen en clockcycles dan jou hobby-versie.

Maar ben je geen extra resources kwijt door het aanmaken van de iterator? Dat kost ook weer tijd lijkt me...

[Verwijderd]

Glimi schreef op 12 december 2003 @ 14:20:
Heb je anders wat meer code, die de foutmelding geeft? Als het veel is evt in een zipje oid, maar dan kan ik er even mee aan de slag.

De code in m'n eerste bericht is alle code die de foutmelding geeft (oke, paar namen zijn veranderd, en ik heb .toLowerCase() erin gezet om aan te geven dat de string die uit de lijst wordt gehaald bewerkt wordt en daarna weer wordt teruggezet.... De werkelijke code die wordt uitgevoerd is een regex-stukje die vreemde tekens wegfilterd en dan de gefilterde string teruggeeft ( of een lege string indien de originele string leeg was of null) Binnen deze functie wordt trouwens wel een Hashtable aangeroepen om objecten mbv. een naam op te kunnen zoeken. Ik weet niet of dit invloed kan hebben.

Het hele project doorsturen is helaas niet echt praktisch ivm omgeving-specifieke dingen (niet veel voorkomende serversoftwarepakketen etc) die uitgelezen worden. Testen zal dan ook niet lukken zonder deze extra softwarepakketten

Maar erg bedankt voor het aanbod.

(Edit01: smilie veranderd)
(Edit02: tekst toegevoegd)

[ Voor 11% gewijzigd door Verwijderd op 12-12-2003 14:29 ]

[Alarmnummer]

Verwijderd schreef op 12 december 2003 @ 14:15:
[...]


Tja, daar kan je over twisten. Iterators zijn daarvoor gebouwd, maar een list heeft zelf alle functies die je nodig hebt om door een lijst te fietsen. Dus je kan een iterator aanmaken en dan door die iterator gaan fietsen, of direkt door de lijst. Mij lijkt het laatste dan efficiënter.

(Edit01: text toegevoegd)

Degene die het beste kan bepalen hoe jij het meest efficient door een lijst kan lopen is natuurlijk degene die die lijst heeft ontwikkeld. Als jij een array list heb, dan is het niet duur om te gaan indexen, maar stel dat jij een linked list hebt, dan is indexen een vrij dure operatie. Daarom is de iterator implementatie van een arraylist ook heel anders dan van bv een linked list.

Het zou zowieso niks uit mogen maken qua uiteindelijke resultaat lijkt me.

Dat ben ik met je eens

Maar ben je geen extra resources kwijt door het aanmaken van de iterator? Dat kost ook weer tijd lijkt me...

speciaal voor deze extra iterator heb ik 512 mb ram er extra bij ingedrukt.

[ Voor 11% gewijzigd door Alarmnummer op 12-12-2003 14:29 ]

[Verwijderd]

Alarmnummer schreef op 12 december 2003 @ 14:28:
[...]

Degene die het beste kan bepalen hoe jij het meest efficient door een lijst kan lopen is natuurlijk degene die die lijst heeft ontwikkeld. Als jij een array list heb, dan is het niet duur om te gaan indexen, maar stel dat jij een linked list hebt, dan is indexen een vrij dure operatie. Daarom is de iterator implementatie van een arraylist ook heel anders dan van bv een linked list.

[...]

Dat ben ik met je eens


[...]

speciaal voor deze extra iterator heb ik 512 mb ram er extra bij ingedrukt.

Hmm, dat over die iterators is wel een goed punt, had er zo nog niet over nagedacht

[Glimi]

Maar ook zou een iterator beter zijn, dan is het nog heel erg raar dat dit een outofbounds geeft Ik duik nog even in de ArrayList implementatie.

[Alarmnummer]

Verwijderd schreef op 12 december 2003 @ 14:31:
[...]


Hmm, dat over die iterators is wel een goed punt, had er zo nog niet over nagedacht

Je kan trouwens met jdk 1.5 zeggen:

code:

for(String s: stringList){
     doeIets met s
}

Onder de grond zit ook stiekum een SimpleIterator (de parent van de Iterator maar dan zonder remove methode).

[Verwijderd]

Alarmnummer schreef op 12 december 2003 @ 14:36:
[...]

Je kan trouwens met jdk 1.5 zeggen:

code:

for(String s: stringList){
     doeIets met s
}

Onder de grond zit ook stiekum een SimpleIterator (de parent van de Iterator maar dan zonder remove methode).

ghehehe Foreach uit c# ? achja, c# is gejat van java dus waarom ook niet

Maar wel erg handig dat er nou een functie voor is, alhoewel ik het ook wel weer grappig vind dat Java met classes/interfaces een leesbare syntax gebruikt (implements etc) terwijl c# puntjes gebruikt, en bij foreach is c# leesbaar en gebruikt java puntjes Mja, misschien heeft dat te maken met welke taal welke functie als eerste implementeerde

[Alarmnummer]

Verwijderd schreef op 12 december 2003 @ 14:45:
[...]


ghehehe Foreach uit c# ? achja, c# is gejat van java dus waarom ook niet

foei, dat mag je niet zeggen.

[Verwijderd]

Alarmnummer schreef op 12 december 2003 @ 14:46:
[...]


foei, dat mag je niet zeggen.

Mja, misschien wel, misschien niet ik vind het in ieder geval toevallig dat het hele idee achter .net etc wel heel erg veel lijkt op het idee achter java, inc. het hele virtual machine (of common runtime dan) gebeuren.

Maar eerlijk is eerlijk, C# is inderdaad niet direkt gejat of gekloond. Hooguit geinspireerd door Java:) (Dat mag je toch wel zeggen? )

Maar das weer een compleet andere discussie, dus zal er ook maar niet teveel over tikken...

Ontopic: Nou heeft de applicatie 1440+ records doorgelopen zonder 1x die exception te gooien. Begrijp er echt weinig van.

[curry684]

Alarmnummer schreef op 12 december 2003 @ 14:46:
[...]
foei, dat mag je niet zeggen.

Ondanks dat ze een paar bugs in Java hebben gefixed is het nog steeds een 1 op 1 kopie syntactisch en technisch gezien, puur en alleen omdat Microsoft op Java geen rechten had en nu op C# alle.

Vloek ik nu in de kerk?

[Alarmnummer]

Verwijderd schreef op 12 december 2003 @ 14:58:
[...]


Mja, misschien wel, misschien niet ik vind het in ieder geval toevallig dat het hele idee achter .net etc wel heel erg veel lijkt op het idee achter java, inc. het hele virtual machine (of common runtime dan) gebeuren.

Heb je wel op die 'niet' link geklikt en gekeken wie degene was waarom het topic was gestart?

[Robtimus]

Alarmnummer schreef op 12 december 2003 @ 14:28:
Als jij een array list heb, dan is het niet duur om te gaan indexen, maar stel dat jij een linked list hebt, dan is indexen een vrij dure operatie. Daarom is de iterator implementatie van een arraylist ook heel anders dan van bv een linked list.

Eh nee, die laatste zin is onzin, geen van beide implementeren ze de iterator() method, die erven ze gewoon van AbstractList. Wat WEL is, is dat LinkedList listIterator() implementeert en een eigen implementatie van ListIterator teruggeeft. Minor difference.

Trouwens 1 hele goede reden om Iterators te gebruiken: het is DE manier (niet de enige) om veilig tijdens het itereren elementen te verwijderen. Ik moet alleen zelf nog wel overstappen bij gebruik van Lists.
ListIterator is ook handig voor het inserten en setten.

[ Voor 8% gewijzigd door Robtimus op 12-12-2003 15:38 ]

[Alarmnummer]

IceManX schreef op 12 december 2003 @ 15:38:
[...]
Eh nee, die laatste zin is onzin, geen van beide implementeren ze de iterator() method, die erven ze gewoon van AbstractList. Wat WEL is, is dat LinkedList listIterator() implementeert en een eigen implementatie van ListIterator teruggeeft. Minor difference.

Lees mijn zin nog eens even goed.

[edit]
Ik zie dat je het idd ook kan verwarren met de iterator methode. Ik bedoel dus het iterator object, maar denk dat dat wel duidelijk was.

[edit2]
Ik zie tot mijn grote verbazing dat de LinkedList idd geen eigen iterator terug stuurt, maar die gebruikt van de abstract iterator. En deze Iterator implementatie werkt gewoon met een index ipv rekening te houden met de LinkedList.

Fijn om te weten dat een iterator over een LinkedList dus vele vele malen trager is dan die over een arraylist en dat terwijl dat denk ik niet had gehoeven.

[ Voor 48% gewijzigd door Alarmnummer op 12-12-2003 15:49 ]

[Verwijderd]

Alarmnummer schreef op 12 december 2003 @ 15:40:
Fijn om te weten dat een iterator over een LinkedList dus vele vele malen trager is dan die over een arraylist en dat terwijl dat denk ik niet had gehoeven.

Ghehehe, mja, das Java Vind het zelf ook al zo logisch dat je om de tijd te weten te komen een calender-object moet aanmaken en per veld moet uitlezen. Wat dat betreft zit c# met die DateTime van .NET een heel stuk logischer in elkaar

[silentsnow]

Is het een mogelijkheid om zelf de grootte van de array bij te houden dmv een simpele int die je steeds increment in de .add methode? Dan hoef je tenminste de .size() niet te gebruiken, en dan kom je misschien iets verder.

[Verwijderd]

silentsnow schreef op 13 december 2003 @ 10:20:
Is het een mogelijkheid om zelf de grootte van de array bij te houden dmv een simpele int die je steeds increment in de .add methode? Dan hoef je tenminste de .size() niet te gebruiken, en dan kom je misschien iets verder.

Zou misschien een idee zijn, maar binnen de applicatie circuleren nogal wat arraylistobjecten en het is dan ook een beetje lastig/resource intensief om van al die objecten counters bij te houden (Ook wordt er gebruikt gemaakt van class-abstractie waardoor het niet altijd even duidelijk is wel class je precies voor je hebt).

Maar ik heb tot nu toe die bug niet weer gezien, dus gooi ik het op een stuiptrekkinkje van Java en ga ik maar gewoon verder met m'n code

[reddevil]

Verwijderd schreef op 12 december 2003 @ 14:27:
[...]


De code in m'n eerste bericht is alle code die de foutmelding geeft (oke, paar namen zijn veranderd, en ik heb .toLowerCase() erin gezet om aan te geven dat de string die uit de lijst wordt gehaald bewerkt wordt en daarna weer wordt teruggezet.... De werkelijke code die wordt uitgevoerd is een regex-stukje die vreemde tekens wegfilterd en dan de gefilterde string teruggeeft ( of een lege string indien de originele string leeg was of null) Binnen deze functie wordt trouwens wel een Hashtable aangeroepen om objecten mbv. een naam op te kunnen zoeken. Ik weet niet of dit invloed kan hebben.

Het hele project doorsturen is helaas niet echt praktisch ivm omgeving-specifieke dingen (niet veel voorkomende serversoftwarepakketen etc) die uitgelezen worden. Testen zal dan ook niet lukken zonder deze extra softwarepakketten

Maar erg bedankt voor het aanbod.

(Edit01: smilie veranderd)
(Edit02: tekst toegevoegd)

Hrmz, de gegevens code kan volgens mij geen fouten opleveren, dus ik denk dat in je eigen functie de fout voorkomt. Kan je niet proberen om die eigen functie te versimpelen zodat hij alleen "" insert ofzo.