7

私はC＃の入門書を読みましたが、それをどうするかわからない場合は例外をキャッチするべきではありません。Javaでプログラミングしているときにそのアドバイスを考えると、例外をどうすればよいかわからないことがありますが、コンパイルエラーを回避するために、それをキャッチするか「浸透」させる必要があります。throws呼び出しツリーのずっと上まで句を含むメソッドを乱雑にしたくないのでRuntimeException、次のように例外をaに「変換」することにしばしば頼りました。実際には「処理」されていない（適切に処理されていない）例外の多くのメソッドに句を追加するthrowsと、冗長で気が散るように見えます。次の悪いスタイルですか？もしそうなら、これに対処するためのより良い方法は何ですか？

try {
  thread.join();
}
catch (InterruptedException e) {
      Console.printwriter.format("%s\n", e.printStackTrace());
  throw new RuntimeException();
}

編集：混乱は別として、パーコレーション例外には別の問題があります。コードの改訂後、おそらくいくつかの不要なthrows句が発生することになります。それらをクリーンアップするために私が知っている唯一の方法は、試行錯誤によるものです。それらを削除して、コンパイラーが文句を言うかどうかを確認します。明らかに、コードをクリーンに保ちたい場合、これは厄介です。

4

4 に答える 4

5

チェックされた例外とチェックされていない例外の間のJavaでの分割は、いくぶん物議を醸しています。

インターフェイスを制御する場合は、通常、署名にthrows句を追加するのが最善の方法です。

例外を処理できない状況にあるが、チェックされた例外シグニチャのために例外をバブルアップさせることが許可されていない場合は、例外を再スローできる例外（多くの場合RuntimeException）にラップするのが一般的な方法です。

ただし、多くの場合、IOExceptionやSQLExceptionなどの別のチェック済み例外を使用することをお勧めします。しかし、それは常にオプションではありません。

ただし、この例では、元の例外を「原因」として含めます。

 throw new RuntimeException(e);

これにより、ロギングの必要性がなくなる可能性もあります（これは、例外を処理できる誰かに延期することもでき、すべての情報がまだそこにあるためです）。

于 2012-11-22T10:07:30.310 に答える
1

例外をどうするかわからない場合は、それを捕まえるべきではありません。したがって、メソッドは例外をスローするようになりました。したがって、実行時の例外でない場合は、throws句を含める必要があります。彼らには何も悪いことはありません。

于 2012-11-22T10:09:37.847 に答える
1

JoshuaBlochのEffectiveJava2nd editionのアドバイスが好きです-抽象化に適した例外をスローします（アイテム61）。

つまり、メソッドから「パーコレート」したい一連の例外に直面した場合は、メソッドにとってより意味的な意味を持つもので例外を再ラップする必要があるかどうかを検討してください。

このようなアプローチには、多くの場合、いくつかの低レベルの例外を1つの高レベルの例外に結合するという心地よい副作用があります。

于 2012-11-22T10:26:29.653 に答える
1

優れたプログラミング手法では、オブジェクトの内部状態を呼び出し元から隠す必要があります。少なくとも私にとっては、これには例外も含まれます。その例外の意味を確認し、クラスの呼び出し元にその意味を表す例外を返す必要があります。

フレームワークがすでにその意味の例外（たとえばIllegalArgumentException）を提供している場合は、新しいオブジェクトをインスタンス化し、何が起こったかを適切に説明した文字列を指定し、発生した例外をカプセル化する必要があります。 Xは..."、e）のために無効です。フレームワークに問題に対する適切な説明的な例外がない場合は、独自の例外セットを作成する必要があります。私は通常、そのプロジェクト/パッケージの一般的な例外（ExceptionまたはRuntimeExceptionを拡張する）を作成し、そこから例外を派生させます。たとえば、私は最近、データベースにアクセスするためにサービスとアプリケーションモジュール全体で再利用される汎用リポジトリプロジェクトを作成しました。DBへのアクセスに使用していたものから呼び出し元を抽象化したかったので、例外からでも、JPAHibernateの例外をカプセル化するためにいくつかの例外を作成することになりました。ここにコードはありませんが、次のようなものでした。

// implementation package
public abstract class GenericRepository<K, E extends<K>> implements IRepository<K, E>{

    //  constructors

    public final void add(E entity){
        // some code

        try{
            //  code that can throw exceptions
        } catch (EntityExistsException e) {
            //  some code
            throw new EntityAlreadyExistsException(e);
        } catch(RuntimeException e) {
            //  some code
            throw new GenericRepositoryException("An unexpected exception occurred while manipulating the database", e);
        }
    }

    //  some other code

}


// exception package
public final class EntityAlreadyExistsException extends GenericRepositoryException{

    public static final String GENERICMESSAGE = "The entity already exists on the table";

    public EntityAlreadyExistsException(Throwable cause){
        super(GENERICMESSAGE, cause);
    }

    //  other constructors

}
于 2012-11-22T11:04:59.693 に答える