16

実装しているインターフェイスで定義されていない例外をスローする必要がある場合に従うべきベストプラクティスは何ですか？

次に例を示します。

public interface Reader
{
    public abstract void read() throws IOException;
}

public class CarrotReader implements Reader
{
    public void read() throws IOException {}
}

public class CupcakeReader implements Reader
{
    public void read() throws IOException, CupcakeException {}
}

この場合、カップケーキを読み取るときに発生する特定の例外があるため、これに関連する例外をスローする必要があります。ただし、Readerはそのインターフェイスでこのタイプの例外を定義していないので、どうしますか？さらに、このタイプの例外はCupcakeReaderに固有であるため、Readerインターフェイスのthrows句にCupcakeExceptionを追加しても意味がありません。これを回避する1つの方法は、Readerにreadを定義させて、 Exceptionなどの親タイプをスローするようにすることですが、そうすると、例外のコンテキストが失われます。この状況であなたは何をすべきですか？ありがとう！

提起されたもう1つの興味深い状況には、制御できないインターフェースが含まれます。この場合、問題が発生したことを示す最良の方法は何ですか？

説明のために、別の例を示します。

public interface Reader
{
    public abstract void read();
}

public class CupcakeReader implements Reader
{
    public void read() throws CupcakeException {}
}

この場合、Readerを変更することはできませんが、 CupcakeReaderのreadメソッドで問題が発生したことを示す必要があります。

4

6 に答える 6

13

代わりに、予期されるタイプの例外を作成する必要がある場合があります。

... catch(CupcakeException e) {
   throw new IOException("The sky is falling", e);
 }
于 2009-08-03T16:14:38.253 に答える
9

例外階層のルートインターフェイスとして機能するReaderExceptionと呼ばれるものを使用します。ReaderExceptionは、下位レベルの例外が原因でスローされる他の例外へのリンクも提供します。

于 2009-08-03T16:11:45.277 に答える
2

例外はインターフェースの一部です。インターフェイスを再定義できる場合は、インターフェイス内のすべての例外に対して汎用の親を定義します。

CupcakeException を IOException の子にすることもできます。

于 2009-08-04T01:13:36.307 に答える
1

チェック例外を使用しないでください。

あなたが示した例は、チェックされた例外が悪い理由の1つです。

ただし、主な理由は、カップケーキ リーダーのユーザーは、関心があるかどうかに関係なく、例外を処理する必要があるためです。

したがって、代わりに：

Value value = reader.read();

あなたは彼にこれを強制しています：

Value value = null;
try {
    value = reader.read();
} catch (Exception e) {
    // now what??
}

value.doSomething();   // potential NPE here

どちらが優れていて、読みやすく、エラーが発生しにくいかを考えて、チェック済み例外の使用をやめてください。

編集：

マイナス評価でビックリです。チェックされた例外が素晴らしいと今でも思っている人はいますか? その場合、チェック済み例外を使用してはならない理由がいくつかあります。

  • チェック例外を使用する最新のフレームワークはありません (Spring、EJB3 など)。
  • コード例の記事はこちら
  • StackOverflowトピック
  • 有効な Java (セクション 58 および 59) -こちら
于 2009-08-03T17:02:07.630 に答える
0

CupCakeException の基本クラスとして機能するより高度な抽象例外を作成する場合、CupCakeException を Reader インターフェースに追加した場合のように、Reader インターフェースを特定の実装にバインドしません。1 つの Exception を別の Exception から継承させない場合、Thorbjørn Ravn Andersen が短いコード例で既に示したように、スロー可能なものを 2 番目の引数として受け取るコンストラクターが例外クラスに存在します。これにより、より抽象的な例外を生成することができ、コードのすべての部分で「エラーが発生した」だけでなく、より高い例外の原因を探すことができます。

于 2009-08-03T16:40:17.663 に答える
0

おそらく、抽象 ReaderSpecificException クラスを作成して Interface に配置し、この抽象クラスから CupcakeException をサブクラス化することができます。

于 2009-08-03T16:11:44.747 に答える