2012-06-13 15 views
7

エラーのスタックトレース(メインスレッドでは発生しない)にメソッドが含まれていないと? 問題の完全なトレース:私は現在、最後に新しいデータでのJTableを更新するSwingWorkerのを使用してバックグラウンドでプロセスを実行しようとしていたJavaライブラリ呼び出しのみを含むStacktraceの例外

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) 

。 このタスクに関連するすべてのコードはここに投稿するには大きすぎますが、エラーの原因を絞り込む方法があるのだろうかと思います。

+0

RuntimeExceptionを追跡することは、宣言または文書化するために必須ではないため、実際には困難です。 – PeterMmm

答えて

5

以外のサイズを持っていることを確認あなたのTableModelにある可能性が最も高いです。

なスタックトレースをデバッグするためには、私は通常、これらのメソッドのいずれかを使用します。

  • は、あなたがそれらの標準のJDKクラスを使用すると、スタックトレースを見て、あなたはすでにかなり良いを得ることができ、いくつかの思考を行います何がうまくいかないかのアイデア(スタックトレースのみを持っているので、この質問の答えに見られるように)
  • IDEに「例外ブレークポイント」を配置してください。少なくとも、デバッガを使用して詳細情報を取得できますスタックトレースで利用可能なもの。自分のオブジェクトを認識しやすくして、問題のあるコードがどこにあるのかを知ることができます。
  • JDKのソースコードをプロジェクトに添付し、JDKのソースコードに定期的なブレークポイントを設定してデバッグを開始できます。
  • 標準のJDKオブジェクトを使用する代わりに、たとえば、次のようにします。正規のJDKクラスを匿名で拡張し、superを呼び出すだけで問題のあるメソッドをオーバーライドします。これにより、問題のあるオブジェクトの問題のあるメソッドにブレークポイントを配置することができます。

これはすべて、同じものに降ります(私のデバッガを取得してください)。何がうまくいかない。そして、あなたが問題を理解したら、それを修正するのはかなりの時間です。

+0

あなたのメソッドはすべて面白いですが、私はもう1つを追加します:自分のコードについて考える。例えば、紙の上をステップインします。 JDKソースのデバッグは、何とか楽しく有益ですが、通常はその原因はありません。 – Carlo

+0

非常に良い答え! –

+0

@Carlo JDKのデバッグを意味しませんでした。むしろ、デバッガを停止して、スタックトレースに含まれるオブジェクトを検査してください。通常は独自のコードで作成します。これは、あなたがオブジェクトを作成したあなたのコードの中にあったものをよりよく理解できるようにするかもしれません(例えば、あなたのコードであなたが作成した値であることがわかっているフィールドに割り当てられた値を認識することによって) – Robin

4

JTable(または新しいモデル)に列がないため、内部コードがDefaultTableColumnModel.getColumnの場合、ArrayIndexOutOfBoundsExceptionが発生します。

あなたの表は、この場合、問題のスタックトレースは、あなたの方法のうちのいずれかが含まれていないかもしれないが、それはそれはあなたが作成したオブジェクトのいずれかが含まれていないという意味ではありません0

+0

それは本当にうまいですし、OPにとっては確かに有用ですが、それはその質問に対する答えではありません。 –

+0

@LucaGerettiどのように答えではありませんか?彼はそれを絞り込む方法を尋ねたので、はい私の答えは正確に答えていないが、OPは明らかに例外を解決したい。 – Vulcan

+0

これは良い暗黙の答えです(手がかりを慎重にスタックトレースを見てください)が、私は別の方法があるのだろうかと思っています。 また、テーブルモデルが編集または変更されるたびにprintlnをいくつか入れます。それは決して70列未満であり、エラーは消えてしまった(????????)。 –

0

@バルカンはあなたの特定の問題を解決しました。

一般的に、スタックトレースにあなたのメソッドが含まれていない場合は、前もって試したことがあり、デーモンスレッドによって実行されているものを探してください。たとえば、この場合、テーブルを混乱させていました。描画時に、メソッドを一切使用せずに、物事が南になりました。

その他の設定項目は、設定ファイル、コマンドラインパラメータ、環境変数などです。

それは、あなたのメソッドがエラーを引き起こさなかったならば、それはそれが混乱する前に起こったことです。

非常にまれなケースですが、もちろん、バグが見つかるかもしれません!

0

rt.jarを使用してjava。*クラスをデバッグし、これらのクラスのトレースとステップ実行を許可するようにIDEを構成することができます。次に、スタックトレースの上位メソッドにブレークポイントを設定し、エラーの原因となったビジュアルコンポーネントで何をしたのかを確認します。

また、スタックトレースを分析するだけで問題に関するヒントを与えることができます。たとえば、この場合はgetColumn()という問題のある行です。そのため、テーブルの列で行ったことになります。インデックス0 >= 0は、期待されているか実際に存在しているカラム数についてのヒントを提供します。

一般的に、根本原因を突き止めるためにコンポーネントの動作を深く理解する必要があります。

1

通常、これらの種類のスタックトレース(Swingレイアウト/ペイント中のNPEまたはIndexOutOfBounds、トレース内のRepaintManager/Look & Feelクラスを参照)は、EDT(イベントディスパッチスレッド)上でSwingコンポーネントを作成/ 。 これには、再描画の原因となるイベントを発生させるTableModelのようなSwingデータモデルの更新が含まれます。

詳細については、「java swing concurrency tutorial」で検索してください。

関連する問題