そこで、本からの引用は次のとおりです。
オーバーライドするメソッドは、オーバーライドされたメソッドによって宣言されたものよりも新しい、またはより広いチェック例外をスローしてはなりません。たとえば、FileNotFoundException を宣言するメソッドは、FileNotFoundException のサブクラスでない限り、SQLException、Exception、またはその他の非実行時例外を宣言するメソッドによってオーバーライドできません。
ここで私の質問です。スーパークラスのメソッドが例外をスローする場合、オーバーライドするメソッドは例外をまったくスローできませんか?
オーバーライドメソッドが例外をスローせず、エラーも発生しなかったJavaでこれを試したからです。
説明してください。
スーパークラスよりも少ない種類の例外をスローするオーバーライド メソッドを宣言できますが、新しい例外を導入することはできません。サブクラス メソッドは、スーパークラス メソッドの動作と互換性がある必要があります。より正確には、サブクラスのオブジェクトをスーパークラスのオブジェクトの代わりに、何も壊さずに置き換えることができる必要があります (throws 句に新しいチェック済み例外を追加すると、それを呼び出すものはそれを処理するためにコードを変更する必要があることになります)。
(この背後にある考え方は、Liskov Substitution Principleです。プログラムは、すべての正確な型について詳細に行き詰まることなく、高レベルでオブジェクトを処理できる必要があります。サブクラスが変更を導入できる場合、プログラムはそれらを選択し、それらを異なる方法で処理すると、抽象化の目的が無効になります。)
そのため、オーバーライド メソッドは、( throws 句を完全に省略することにより) チェック済み例外をまったくスローしないと宣言できます。これは、呼び出し元を変更する必要がないためです。
java.io などの JDK には、サブクラスがスーパー クラスによって宣言された例外をスローできない可能性がある例があります ( ByteArrayOutputStreamのclose メソッドを参照してください)。ここで、close メソッドは IOException をスローしないため、throws 句を削除することができます。(おそらく、誰かが IOException をスローしたバージョンでサブクラス化したいという可能性に残されましたか?)