4

これを行う理由はありますか?

void foo() throws Exception
{
    // Do something potentially exceptional
}

既存またはカスタムの例外をスローするのではなく?

4

10 に答える 10

5

私が考えることができる可能性のある2つのケースがあります-私が考えることができる最初の同様のケースは、実装するときfinalize()です、あなたは投げなければなりませんThrowable：

@Override
protected void finalize() throws Throwable {
    super.finalize();
}

...ただし、finalizeを使用すること自体は推奨されないという意見もあります。

潜在的な2番目のケースは、メソッドがをスローする可能性のある（不適切に記述された）ライブラリを使用するException場合です。この場合、その特定のメソッドで処理したくない場合は、スタックにスローするしかありません。

個人的には、それが私だったとしたら、RuntimeExceptionでラップする可能性が高いです。

public void doSomething() {
    try {
        int x = libraryThing.badMethod(); //Library method that throws "Exception"
    }
    catch(Exception ex) {
        throw new RuntimeException("Couldn't do something", ex);
    }
}

RuntimeExceptionただし、この場合、コンストラクターの2番目の引数は重要です。これがスローされると、スタックトレースの元の例外が（ "Caused by：x"）として保持されるためです。もちろん、RuntimeExceptionのより具体的なサブクラスを見つけて、そのコンテキスト（IllegalArgumentExceptionたとえば）に関連することを保証できる場合は、それを使用する方が適切です。

ただし、通常のコードに関しては、違います。ほとんどの場合、アンチパターンであると主張します（通常、怠惰によって引き起こされるものです！）

副次的な点として、aをスローすることRuntimeExceptionはそれほど悪くはありません-それでも非常に不特定ですが、少なくとも呼び出し元にすべてを明示的にキャッチするように強制することはありません。

于 2012-09-07T15:28:17.550 に答える
3

私はそれをしません。何が起こったかについての最小限の情報を提供します。

現在のベストプラクティスは、チェックされていない例外を優先することだと思います（これはC＃の方法です）。foo（）メソッドは、チェックされた例外をキャッチし、RuntimeExceptionでラップします。

例外を詳しく説明するか、よりビジネス固有のカスタム例外でラップするか、RuntimeExceptionをラップします。

于 2012-09-07T15:28:19.983 に答える
3

テストメソッドでこれを行うことがよくあります。

@Test
public void testSOmething() throws Exception {

これは、例外がスローされるかどうかを特にテストしていない単体テストの標準的な署名です (ほとんどのテストです)。

これらのテスト以外では、テストがどの例外をスローするかは気にしません。これらの場合に例外をスローすると、テスト対象のメソッドの失敗を表すためです。

ただし、本番コードではこれを行うことはありません。

于 2012-09-07T15:31:49.423 に答える
3

メソッドが任意の例外をスローできるようにします。

これは、任意のコードが既知のシグネチャを持つメソッドで実行されるフレームワーク コンテキストで見られる場合があります。その文脈で「良い」かどうか...まあ。フレームワーク固有の例外またはランタイム例外が表示されます。

それ以外は、一般的にアンチパターン、IMO です。

于 2012-09-07T15:30:03.833 に答える
2

throws Exception実際のリストが非常に長くて面白くない場合は、宣言することができます。たとえば、リフレクションを介してメソッドを呼び出すと、かなりの数の例外が発生する可能性があります。

于 2012-09-07T15:29:29.000 に答える
2

Java 独自のCallableインターフェイスを実装している可能性があります。それはそれについて要約します。他の誰かのコードが実行される可能性のある上部構造を提供しているが、内部でチェックされたすべての例外を強制的にキャッチするようにそれらを制限したくない場合。これはあなた自身のライブラリ自体の悪い設計ではなく、そもそもチェック例外の悪い設計の危険であると主張することができます (しかし、そうすれば、SO の質問ではなく、聖戦が発生することになります)。

于 2012-09-07T15:34:45.840 に答える
1

一般に、それはコードの悪い設計、または基礎となるライブラリの悪い設計のいずれかを意味します。正当な理由もなく「例外をスローする」と宣言していることに気付いた場合は、代わりにRuntimeExceptionをスローすることを検討してください。特にライブラリコードで。

于 2012-09-07T15:28:08.353 に答える
0

一般に、他の誰かによって実装され、非常に異なる実装を持つことができるインターフェイスで宣言されたメソッドに対して「例外をスローする」ことが許容されます（スローされる可能性のある実装を制限したくないでしょう）。

メソッドからスローされる例外が非常に多い場合にも、許容できると思います。

私はそれをアンチパターンとは見なしませんが、怠惰からよく使われるイディオムです。

于 2012-09-07T16:01:59.107 に答える
0

多くの場合、テスト/簡単なコードで行われますが、それは非常に合理的です。

リストが長くて退屈な場合に行われることがありthrowsます - やや合理的です

また、一部の開発者/プロジェクトは、「チェック済み」例外について異なる哲学を持っているため、すべてに対してこれを行っています。世界のその他の地域"。

于 2012-09-07T16:58:50.220 に答える
0

ビジネスルールに基づいて、独自の例外を定義します

public void doSomething() {
    try {
        int x = 10/0; //Library method that throws "Exception"
    }
    catch(Exception ex) {
        throw new Exception("this doesn;t work.there is exception", ex);
    }
}

これは Exception メソッドをオーバーライドします。

class Exception
{
   Exception()
   {
   }

   Exception(String msg)
   {
      this.msg=msg;      
   }
}
于 2012-09-07T16:48:01.660 に答える