异常与Stacktrace只包含java库调用

本文介绍了异常与Stacktrace只包含java库调用的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

如果堆栈跟踪的错误（不在主线程中发生）不包含任何方法，可以采取什么行动来查明出错的情况？
问题的完整跟踪：

为了调试这样的堆栈跟踪，我通常使用以下方法之一：

做一些想法，你在哪里使用这些标准的JDK类，通过查看stacktrace，你可以已经得到一个很好的想法出了什么问题在这个问题的答案中被看到，因为我们只有堆栈跟踪）

在你的IDE中放置一个'Exception断点'，这将至少允许你使用你的调试器并获得更多的信息那么stacktrace中有什么可用的可以使您更容易识别自己的对象，并了解您的代码中的问题所在。

将JDK源代码附加到项目中，并在JDK源代码中放置一个常规断点，所以你可以开始调试。

而不是使用标准的JDK对象，例如常规JDK类的匿名扩展，并通过调用 super 来覆盖有问题的方法。这允许您在有问题的对象的有问题的方法中放置断点。

这一切都归结于（第一种方法除外）相同：让我的调试器进行，所以我可以更仔细地检查所有相关的对象，以了解出了什么问题。一旦你明白了这个问题，修复它是大部分时间非常简单的。

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.

解决方案

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

这篇关于异常与Stacktrace只包含java库调用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！