8

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.

Christopher Hubert
  • 83
  • 5
  • Tracking down a RuntimeException is really hard, because they are not mandatory to declare nor to document. – PeterMmm Jun 13 '12 at 10:31

5 Answers5

6

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

Robin
  • 36,233
  • 5
  • 47
  • 99
  • Your methods are all really interesting, but I would add one more: think about your own code. For example stepping through it on paper. Debugging JDK source is somehow fun and instructive, but usually the culprit is not there. – Carlo Jun 13 '12 at 10:40
  • @Carlo I did not mean to debug the JDK. Rather just have you debugger stop there and inspect the objects involved in the stacktrace, which you typically created in your own code. This might give you a better understanding of were in your code you created the object (e.g. by recognizing a value assigned to a field you might know it is the value you created at location 'x' in your code) – Robin Jun 13 '12 at 10:47
  • 1
    @Robin yeah, I got that, I just wanted to underline that your interesting method should be used as a final effort, after some hard headbanging ;) – Carlo Jun 13 '12 at 11:00
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.

FThompson
  • 28,352
  • 13
  • 60
  • 93
  • That is true and fine and certainly useful to the OP, but it is not an answer to the question. – Luca Geretti Jun 13 '12 at 10:27
  • @LucaGeretti How is it not an answer? He did ask how to narrow it down, so yes my answer isn't exactly answering it, but OP obviously wants to resolve the exception. – FThompson Jun 13 '12 at 10:30
  • It's a good implied answer (look at the stack trace carefully for clues) but I'm wondering if there's another way. Also, I put in a few println's at every point the table model is edit or changed. It never has fewer than 70 columns and the error has disappeared (????????). – Christopher Hubert Jun 13 '12 at 10:34
  • @Vulcan: then we agree :) The OP asked for "an error", not "the error below". – Luca Geretti Jun 13 '12 at 11:18
2

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.

Walter Laan
  • 2,956
  • 17
  • 15
0

@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!

Miquel
  • 15,405
  • 8
  • 54
  • 87
0

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.

David Oliván
  • 2,717
  • 1
  • 19
  • 26