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

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