24

「スロー」句と互換性がないために、例外にどのような理由があるのか​​ 誰にも教えてもらえますか

例えば：

class Sub extends Super{

    @Override
    void foo() throws Exception{

    }

}

class Super{

    void foo() throws IOException{

    }
}

Exception Exception は Super.foo() の throws 句と互換性がありません

4

4 に答える 4

32

完全なコード サンプルがなければ、私は推測することしかできません: サブクラスのメソッドをオーバーライド/実装していますが、サブクラス メソッドの例外仕様は、スーパークラス/インターフェイス メソッドの例外仕様と互換性がありません (つまり、サブセットではありません)。

これは、基本メソッドが例外をまったくスローしないように宣言されている場合、またはたとえばjava.io.IOException(java.lang.Exceptionメソッドのサブクラスがここでスローしようとしている) 場合に発生する可能性があります。基本クラス/インターフェースのクライアントは、そのインスタンスが基本メソッドによって宣言されたコントラクトに従うことを期待しているため、そのメソッドの実装からスローすると、コントラクト (およびLSPException )が壊れます。

于 2012-05-09T09:38:46.553 に答える
-1

チェック例外は、発生する可能性のある特定の問題に対処する準備が整っていることをメソッドの呼び出し元が期待する状況で使用することを目的としています。の呼び出し元BaseFoo.Bar()が を処理する必要がない場合FnordException、メソッドは呼び出し元がいずれかDerivedFoo.Bar()を処理することを期待できません(呼び出し元の多くは、それをスローするFnordException準備ができていなかったものと同じであるため)。BaseFoo.Bar()

概念的には、それは素晴らしいことです。実際には、それほど多くはありません。問題は、この言語のチェック例外の設計では、特定の問題を適切に処理する準備ができている呼び出し元がいないか、すべての呼び出し元が問題を処理する準備ができていることを前提としていることです。実際の通常の状態では、呼び出し元が例外を処理する準備ができていない場合があります。一部の呼び出し元が処理できる例外であってもです。ほとんどの場合、コードが明示的に予期していないチェック済み例外を受け取った場合の適切なアクションは、それを未チェック例外でラップしてスローすることです。皮肉なことに、「throws」句を追加してチェック済みの例外をバブルアップさせるという最も簡単な方法は、おそらく正しい可能性が最も低い方法です。いくつかのケースがありますが（例IOException) そのような動作が理にかなっている場合 (たとえば、ファイルからコレクションを読み取ろうとする場合、1 つの項目の読み取り中の I/O エラーはコレクションの読み取り中の I/O エラー)、ネストされたメソッド呼び出し内から例外がスローされます。外側のメソッドによってスローされた同じタイプの例外とは異なる条件を表し、後者を処理する準備ができているコードは、前者を処理する準備ができていない可能性があります。

あなたの状況では、呼び出し元がそれを処理できない可能性が高いことに注意して、それをキャッチIOExceptionして から派生した他の型にラップすることが最善の策かもしれません。RuntimeException

于 2013-04-16T17:59:59.777 に答える
-1

インターフェイスでスローを宣言したことを確認してください。実行しても問題が解決しない場合は、プロジェクトを保存/再構築してみてください。

于 2016-06-29T20:20:27.107 に答える