2

Exception クラスを拡張して CustomExceptionを作成すると、コンパイラによってチェックされますが、RuntimeExceptions は Exception クラスを拡張してもコンパイラによってチェックされません

これはコンパイラでどのように確立されますか。JLSで、その理由を説明しているセクションを見つけました。

実行時例外がチェックされない理由 実行
時例外クラス (RuntimeException とそのサブクラス) は、コンパイル時のチェックから除外されます。Java プログラミング言語の設計者の判断では、そのような例外を宣言する必要があることは、正当性を確立する上であまり役に立たないからです。プログラムの。Java プログラミング言語の操作と構造の多くは、実行時例外を引き起こす可能性があります。コンパイラーが利用できる情報、およびコンパイラーが実行する分析のレベルは、通常、このような実行時例外が発生しないことを証明するには十分ではありません。そのような例外クラスの宣言を要求することは、プログラマーにとって単純に苛立たしいことです。

マーカー インターフェイスの場合のように、舞台裏で何かが起こっているのでしょうか。

それがどのように行われるか、またすべてのチェック済み例外に親クラスがない理由を説明できるソースを探していますか?

4

3 に答える 3

2

マーカー インターフェイスの場合のように、舞台裏で何かが起こっているのでしょうか。

RuntimeExceptionのすべてのサブクラスがチェック例外であるというルールから除外されるという事実Exceptionは、単に仕様の一部です。

ルールに対するこの例外がどのように実装されるかは、コンパイラに依存します。

于 2012-07-17T14:27:52.013 に答える
2

コンパイラは、Error と RuntimeException のサブクラスを除くすべての Throwable サブクラスをチェックします。Throwable がこれらのクラスのサブクラスであるかどうかを確認するだけです。

注:エラーまたは例外ではないThrowableのサブクラスを持つことができ、それがチェックされます。

于 2012-07-17T14:29:58.307 に答える
1

いつでも、だれかがあなたのプログラムにゼロを入力できます。除算すると、ゼロ除算エラーが発生し、RuntimeExcpetion呼び出されArithmeticExceptionた .

ここで、すべての除算ステートメントの周りに try / catch ブロックを含める必要がある場合、コードはエラー処理で雑然とし、コードの主な目的の可読性を損なうことになります。ゼロエラーで割る)。

Java には、可読性と堅牢性のバランスをとるか、可読性を高めるいくつかの「仮定」を使用してすべてのケースで堅牢性を許可するかのいずれかを選択できました。言い換えれば、Java 言語がレイアウトされていたとき、読みやすさと堅牢性のバランスをとるという決定は、ユーザーが作成したソース コードを汚染することと、ArithmeticExcpetion除算演算の周りの s を取得する必要があることの間の決定のように見えました。常に堅牢性を確保するが、特定の種類のExceptions を必要なキャプチャの対象にしないという代替手段は、ソース コードの読みやすさに影響を与えずにプログラムの堅牢性を確保します (ただし、言語には 2 つのカテゴリがあるため、言語が少し複雑であることがわかります)。のException)。

于 2012-07-17T14:41:47.693 に答える