throws キーワードはスレッドの run メソッドでは使用できないことを読みました。それが設計上の問題なのか、それともこれを許可しない本当の理由があるのか を知りたいです。
5 に答える
Thread.run()
は、Java コンソール アプリの がチェック済み例外をスローしないのと同じ理由で、チェック済み例外をスローしないと宣言されていstatic main(String args)
ます。それをキャッチするコードを記述する方法はありません。(両方のメソッドは通常、コードではなく、Java ランタイム環境によって呼び出されます。) いずれのメソッドも未チェックの例外 ( RuntimeException
、Error
、およびそれらのサブクラス) をスローする可能性があることに注意してください。Java ランタイム環境がそれらを処理します (通常、あまり適切ではない方法で)。
Thread
主な理由は、例外をキャッチする人がいないことです。例外は、あなたまたはそれを含む に登録する可能性のあるすべてのキャッチ ハンドラーを除きますThreadGroup
。
RuntimeException
前述のハンドラーで終了する を引き続きスローできることに注意してください。
run()
(ちなみにの戻り値についても同じ理屈が使えますvoid
。)
問題は、呼び出しコンテキストが新しいコンテキストで実行されるようになったため、戻り値または例外を取得できないことです (これが新しいスレッドのすべての意味です)。ただし、 Thread.setDefaultUncaughtExceptionHandler () を使用できます
まあ、Runnable's
run()
メソッドは戻ることも、チェックされた例外をスローすることもできません...おそらく、Javaの設計者は、ほとんどが別のプロセスである別のスレッドで例外をスローする価値がないと考えました...
しかし、後でJava 1.5インターフェースから 、チェックされた例外を返したりスローしたりできるメソッドCallable<T>
が付属しています...call()
Run 自体は例外をスローしません。.start() を呼び出す (run() 関数を呼び出す) ときに行っていることは、新しいスレッドでパスをたどり続けるようにプログラムに指示することだけです。関数呼び出しと run() 関数内のすべてが例外をスローする可能性があります。run() 自体には実行時エラーの可能性はありません。実行時エラーが発生した場合、それはプロセス エクスプローラー、ハンドラー、または OS レベルの問題が発生したためであり、プログラムで処理できるものではありません。