以下は、イベントディスパッチスレッドでスローされた例外をキャッチするコードです。
package com.ndh.swingjunk;
import java.awt.EventQueue;
import javax.swing.JFrame;
public class EntryPoint {
public static void main(String[] args) {
Thread.setDefaultUncaughtExceptionHandler(new MyExceptionHandler());
// System.setProperty("sun.awt.exception.handler", MyExceptionHandler.class.getName());
EventQueue.invokeLater(new Runnable()
{
public void run()
{
new SomeWindow("foo").setVisible(true);
}
});
}
}
class SomeWindow extends JFrame {
public SomeWindow(String title) {
this.setTitle(title);
this.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
throw new RuntimeException("hello");
}
}
イベントディスパッチスレッドでスローされた例外がUncaughtExceptionHandlerで処理されないという警告を見てきましたが、私の例ではそうではありません。登録行がコメント化されていても、残されていても同じように機能します。私の例はなんとなくめちゃくちゃですか、それとも例外ハンドラをsun.awt.exception.handler不要に登録していますか？
EDTのクラス（java.awt.EventDispatchThreadこのクラスは、javadocのそれを見ていないプライベートパッケージが）AWTの起源以来、多くのことを変更しました。
ではJDK6、あなたは、このクラスが正しくEDT内occuring例外を処理できることがわかります。現在のバージョンでは、例外処理は少し複雑です。
sun.awt.exception.handlerプロパティを設定した場合、ハンドラーは、EDT内で呼び出された開発者のコードによってスローされたすべての例外に対して呼び出されます（以前のJDKバージョンとの互換性が保証されます）。UncaughtExceptionHandlerし、スニペットが示すように、デフォルトでそれをキャッチできます。しかし（これは非常に重要です）、EDTのコードを注意深く見ると、モーダルダイアログが表示されているときにEDTで例外が発生すると、このメカニズムが機能しないことがわかります（これはEDTが原因だと思います）そしてEventQueue管理はかなり複雑であり、私はあえて " 乱雑 " と言ってもいいでしょう：多くのコードはハックのように見えます）。
この正確な状況でSystem.errは、sun.awt.exception.handlerプロパティを設定した場合を除いて、例外はに記録されます。デフォルトUncaughtExceptionHandlerを持つことは役に立ちません。
つまり、アプリケーションがモーダルダイアログを使用していないことを確認できる場合（ただし、ダイアログもモーダルであることを忘れないでください）を除いて、sun.awt.exception.handlerプロパティを気にする必要がありますJOptionPane。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加