Exception with Stacktrace containing only java library calls

Question

What possible course of action could one take to find out what went wrong if the stack trace of an error (that does not take place in the main thread) does not contain any of your methods? The full trace in question:

Exception in thread "AWT-EventQueue-0" java.lang.ArrayIndexOutOfBoundsException: 0 >= 0
    at java.util.Vector.elementAt(Unknown Source)
    at javax.swing.table.DefaultTableColumnModel.getColumn(Unknown Source)
    at javax.swing.plaf.basic.BasicTableHeaderUI.getHeaderRenderer(Unknown Source)
    at javax.swing.plaf.basic.BasicTableHeaderUI.getHeaderHeight(Unknown Source)
    at javax.swing.plaf.basic.BasicTableHeaderUI.createHeaderSize(Unknown Source)
    at javax.swing.plaf.basic.BasicTableHeaderUI.getPreferredSize(Unknown Source)
    at javax.swing.JComponent.getPreferredSize(Unknown Source)
    at javax.swing.ViewportLayout.preferredLayoutSize(Unknown Source)
    at java.awt.Container.preferredSize(Unknown Source)
    at java.awt.Container.getPreferredSize(Unknown Source)
    at javax.swing.JComponent.getPreferredSize(Unknown Source)
    at javax.swing.ScrollPaneLayout.layoutContainer(Unknown Source)
    at java.awt.Container.layout(Unknown Source)
    at java.awt.Container.doLayout(Unknown Source)
    at java.awt.Container.validateTree(Unknown Source)
    at java.awt.Container.validate(Unknown Source)
    at javax.swing.RepaintManager.validateInvalidComponents(Unknown Source)
    at javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(Unknown Source)
    at java.awt.event.InvocationEvent.dispatch(Unknown Source)
    at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
    at java.awt.EventQueue.access$000(Unknown Source)
    at java.awt.EventQueue$1.run(Unknown Source)
    at java.awt.EventQueue$1.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.AccessControlContext$1.doIntersectionPrivilege(Unknown Source)
    at java.awt.EventQueue.dispatchEvent(Unknown Source)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
    at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
    at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
    at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
    at java.awt.EventDispatchThread.run(Unknown Source)

I was currently trying to run a process in the background using SwingWorker that at the end updates a JTable with new data. All the code related to this task is far too large to post here and I'm wondering if there is a way to narrow down the source of the error.

Answer 1

Typically these kind of stack traces (NPE or IndexOutOfBounds during Swing layout/painting, see the RepaintManager/Look&Feel classes in the trace) are caused by you not creating/modifying Swing components on the EDT (event dispatch thread). That includes updating Swing data model like TableModel which fire events which will cause a repaint.

Search on "java swing concurrency tutorial" for more info.

Answer 2

You can debug the java.* classes, using rt.jar and configuring your IDE to allow tracing and stepping into these classes. Then put a breakpoint in the upper methods of the stack trace and try to figure what did you do with the visual component that causes the error.

Alternatively only analyzing the stack trace could you give a tip about the problem, for example in this case is getColumn() the problematic line, so should be anything you did with the table columns. The index 0 >= 0 give you another tip about the number of columns expected or really present.

Generally you need deep understanding of behavior of components in order to figure out the root cause.

Answer 3

@Vulcan solved your specific problem.

In general, if the stack trace doesn't involve any of your methods, look for stuff you have tinkered with before, and which is now being executed by some daemon thread. For example in this case you messed with the table, and at drawing time, without using any of your methods, things went south.

Other things to look for are invalid configuration parameters, be it config files, command line parameters, environment variables and the like.

And that's that, if your methods didn't cause the error, then it's something that happened before that messed things up.

In very very rare cases, of course, you may find a bug!

Answer 4

The stacktrace may not contain any of your methods, but it does not mean it does not contain any of the objects you created, In this case, the problem is most likely located in your TableModel.

In order to debug such a stack trace, I typically use one of these methods:

• do some thinking where you use those standard JDK classes and by looking at the stacktrace you can already get a fairly good idea of what goes wrong (as can be seen by the answers on this question as we only have the stack trace)
• place an 'Exception breakpoint' in your IDE which will at least allow you to use your debugger and obtain more information then what is available in a stacktrace. Might make it easier to recognize your own objects and getting an idea where in your code the problem is situated
• attach the JDK source code to your project and place a regular breakpoint in the JDK source code, so you can start debugging.
• Instead of using the standard JDK object, make e.g. an anonymous extension of the regular JDK class and override the problematic method by just calling super. This allows you to place a breakpoint in the problematic method of your problematic object

This all comes down (except the first approach) to the same: get my debugger going so I can examine all related objects more carefully to understand what goes wrong. And once you understand the problem, fixing it is most of time rather trivial

Answer 5

Your JTable (or your new model) has no columns, causing an ArrayIndexOutOfBoundsException when the internal code calls DefaultTableColumnModel.getColumn.

Ensure your table has a size other than 0.