Java.lang.Throwableがクラスなのはなぜですか？
Java-ableで終わる形容詞はインターフェースSerializable、Comparableなどです...では、なぜThrowableはクラスなのですか？ Throwableがインターフェースである場合、例外処理はより簡単になりますか？（編集：たとえば、例外クラスはException/RuntimeExceptionを拡張する必要はありません）。
明らかに、今それを変更することは問題外です。しかし、それを抽象化することはできますか？それはthrow new Throwable()の悪い習慣を避けませんか。
では、なぜThrowableはクラスなのですか？
私は2つの理由を考えることができます：
- 例外には状態があります。特に、メッセージ、原因、およびスタックトレース。
- JVMが効率的なcatchブロックを実装する方が簡単です。クラス階層チェックは、インターフェースチェックよりも安価です。
Throwableがインターフェースであれば、例外処理は簡単ではないでしょうか。
例外がクラスであるかインターフェイスであるかに関係なく、例外処理は難しいトピックです。 Javaプログラマーが、クラス階層ではなく任意のインターフェースに基づいてキャッチブロックを並べ替える必要がある場合は、実際には難しくなると思います。
しかし、それを抽象化することはできますか？
理論的にはそうです。実際には、ありません。コードが多すぎるのは、getStackTraceを呼び出すためにThrowableのインスタンスを作成できるかどうかにかかっています。
ジェームズゴスリングが彼の決定を説明した方法は次のとおりです。
Java開発者接続プログラム：
Throwableがインターフェースではないのはなぜですか？その名前は、そうあるべきだったことを示唆しています。クラスだけでなく、型、つまりtry {} catch (<some interface or class>)のようなものに対してcatchできること。これにより、[the] Java [プログラミング言語]の柔軟性が大幅に向上します。James Gosling：
Throwableと他の人たちがインターフェースではない理由は、私たちが決めた、またはかなり早く決めたからですオン。スローされるすべての例外に関連付けられた状態を設定することにしました。そして、インターフェースではそれを行うことはできません。あなたはクラスでのみそれを行うことができます。そこにある状態は基本的に標準です。メッセージがあり、スナップショットがあり、そのようなものがあります—それは常にそこにあります。また、Throwableをインターフェースにすると、古いオブジェクトをThrowableのものにするために割り当てたいという誘惑に駆られます。一般的なオブジェクトをスローすることはおそらく悪い考えであり、スローしたいものは、例外の性質と何が起こったのかを実際にキャプチャする例外を意図したものでなければならないというのは、スタイル的には悪い考えです。それらは単なる一般的なデータ構造ではありません。
参考文献
よくHashtableも具体的なクラスです！ハッシュできるもの。
クローン可能とは何ですか？正しい英語の単語ではありません。