This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 29255 - Catch and suppress ArrayIndexOutOfBoundsException exception
Summary: Catch and suppress ArrayIndexOutOfBoundsException exception
Status: VERIFIED DUPLICATE of bug 48993
Alias: None
Product: platform
Classification: Unclassified
Component: Explorer (show other bugs)
Version: 3.x
Hardware: Sun All
: P3 blocker (vote)
Assignee: Petr Nejedly
URL:
Keywords: RANDOM
Depends on:
Blocks:
 
Reported: 2002-12-03 21:47 UTC by John Baker
Modified: 2008-12-22 16:45 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description John Baker 2002-12-03 21:47:33 UTC 
Many users have complained about the
ArrayIndexOutOfBoundsException.
It occurs randomly, so there doesn't seem to be a
reproducible case.
Can this exception be caught and suppressed?


*********** Exception occurred ************
Tue Dec 03 13:36:38 PST 2002:
java.lang.ArrayIndexOutOfBoundsException: 21 >= 0
java.lang.ArrayIndexOutOfBoundsException: 21 >= 0
        at java.util.Vector.elementAt(Vector.java:427)
        at
javax.swing.tree.VariableHeightLayoutCache.getRowContainingYLocation(
VariableHeightLayoutCache.java:926)
        at
javax.swing.tree.VariableHeightLayoutCache.getPathClosestTo(VariableH
eightLayoutCache.java:313)
        at
javax.swing.plaf.basic.BasicTreeUI.getClosestPathForLocation(BasicTre
eUI.java:464)
        at
javax.swing.plaf.basic.BasicTreeUI.paint(BasicTreeUI.java:1088)
        at
javax.swing.plaf.metal.MetalTreeUI.paint(MetalTreeUI.java:143)
        at
javax.swing.plaf.ComponentUI.update(ComponentUI.java:142)
        at
javax.swing.JComponent.paintComponent(JComponent.java:537)
        at
javax.swing.JComponent.paint(JComponent.java:804)
        at
javax.swing.JComponent.paintChildren(JComponent.java:643)
        at
javax.swing.JComponent.paintWithOffscreenBuffer(JComponent.java:4742)
        at
javax.swing.JComponent.paintDoubleBuffered(JComponent.java:4688)
        at
javax.swing.JComponent._paintImmediately(JComponent.java:4632)
        at
javax.swing.JComponent.paintImmediately(JComponent.java:4464)
        at
javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:410)
        at
javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(System
EventQueueUtilities.java:117)
        at
java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178)
        at
java.awt.EventQueue.dispatchEvent(EventQueue.java:443)
[catch] at
java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchTh
read.java:191)
        at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThre
ad.java:144)
        at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
        at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:130)
        at
java.awt.EventDispatchThread.run(EventDispatchThread.java:98)
Comment 1 Marian Mirilovic 2002-12-04 11:19:36 UTC 
JDK? Steps to reproduce?

Stack trace is from JDK, none line from NetBeans/S1S.

In my opinion we cannot do anything. Peter ?
Comment 2 Peter Zavadsky 2002-12-05 11:32:26 UTC 
Well, I guess we can't anyway it is about JTree, so putting it first
to explorer, if there are some comments. Maybe we are hacking it too much?
But I recommend to move it to jdk team.
Comment 3 John Baker 2002-12-05 16:45:25 UTC 
This is a random exception.
JDK 1.4.1, Solaris 9.
Comment 4 Jesse Glick 2002-12-09 16:16:41 UTC 
Such a stack trace could result from our manipulating some part of the
tree outside the event thread, I guess. Trung might know how to catch
such things. Anyway it is true that Swing code is terrible at
reporting the actual case of such runtime exceptions. I don't think
such an exception should be caught and ignored. We should either
figure out what we are doing wrong, or give up and pass it on the to
Swing team under the assumption that there is no bug in NB code.
Comment 5 Jiri Rechtacek 2003-02-19 17:11:39 UTC 
I don't plan investigate in 3.5.
Comment 6 _ tboudreau 2003-03-03 10:36:31 UTC 
Using large model (aren't we doing that now?) will probably get
rid of this exception since items in the tree will be fixed height,
and no layout info should be cached and used.
Comment 7 Jiri Rechtacek 2004-04-23 10:45:32 UTC 
Assigned to new owner.
Comment 8 Petr Nejedly 2004-08-01 18:11:34 UTC 
Does it occur lately?
I have never seen it myself and we're several releases ahead already...
Comment 9 Petr Nejedly 2004-09-15 13:57:49 UTC 

*** This issue has been marked as a duplicate of 48993 ***
Comment 10 Tomas Danek 2005-07-11 12:26:46 UTC 
ver as dup