1

テキスト ファイルを読み取って分析するコード ベースを見つけました。例外の使用方法に少し混乱しています。拡張クラスが例外のエラー メッセージのみを返す場合、例外が定義されているAppFileReaderException別のクラス。extendsまた、関数getSymbol()は と の両方throwsを使用しtry and catch blockます。error()関数には例外ハンドラーもあり、ネストされた例外が発生する可能性があります。基本的な try と catch で十分な場合に、このような例外処理を行う利点はありますか? throws例外クラスを拡張し、両方を組み合わせてtry-catchブロックする理由はありますか? これらはオーバーキルですか、それともそのような構造を持つ正当な理由がありますか?

package AppName;    
import java.io.FileNotFoundException;
import java.io.FileReader;
import java.io.IOException;
import java.io.LineNumberReader;

public class AppFileReader {


    // 
    public char getSymbol() throws AppFileReaderException {
        try {

        //do something

       } catch (Exception e) {
            error("IO Error: " + fileName + "@" + currentLineNumber);
        }
        return somechar;
    }


    public void error(String errorMsg) throws AppFileReaderException {
        throw new AppFileReaderException(errorMsg);
    }

    public AppFileReader(String fileName) throws FileNotFoundException {
        reader = new LineNumberReader(new FileReader(fileName));
        this.fileName = fileName;
    }

}

//------------------------------------------------ ------------------

の拡張クラスAppFileReaderExceptionは次のとおりです。

package AppName;
public class AppFileReaderException extends Exception {


    public AppFileReaderException(String msg) 
    {
        super(msg);
    }
}
4

3 に答える 3

2

基本例外クラスから独自の例外を派生させることは非常に良い考えです。

1) 異なる例外オブジェクトを個別に処理できます。

2) 多くの場合、関数には "throws ..." という接尾辞が付いており、呼び出し元にどのような例外が予想されるかを伝えます。これにより、プログラムの安定性が向上します。

Java には multicatch 例外構文があることに注意してください。

Catch (exception1 | exception2 | ... e) ここで、e はキャッチされたオブジェクトです。そのような例外タイプを同等に扱いたい場合は、これを使用します。

于 2013-05-19T10:52:13.943 に答える
2

まず、error()メソッド (関数ではありません!) には処理がありません。指定されたメッセージで例外をスローするだけです。

メソッドを呼び出すときに、独自の例外クラスを作成すると便利な場合があります。だからあなたは次のようなことができます

public void methodThatCallsLibrary() {
   try {
      doSomething();
      new AppFileReader().getSymbol();
      doOtherSomething();
   } catch (AppFileReaderException afre) {
     // handling specific to appFileReader
   } catch (Exception e) {
      // handling related to the rest of the code.
   }
}

とはいえ、ここのシステムは少し奇妙です。メソッドで例外を作成することにより、例外error()のスタックトレースは、例外が発生する可能性のあるすべての場所で同じになります。また、IOException をマスクするだけのように見えるので、おそらく IOException 自体を転送します (そうでない場合は、最終的にスローされる例外にネストされた例外を含めて、より良いデバッグ情報を提供します)。

于 2013-05-19T10:49:27.480 に答える
0

Java のチェック例外と非チェック例外のシステムは実験的なものでしたが、ほとんどのプログラマーはこれは良い概念ではないと考えています。さらに、チェックされた例外階層は設計が不適切です。たとえば、リフレクションを使用して何かを行う場合、4 つまたは 5 つの個別の例外をキャッチする必要があります。

実際には、最新の Web アプリケーションのほとんどすべての Bean コードは、IO、SQL (およびおそらくリフレクション) で何かを行ういくつかの関数を呼び出すため、チェック例外システムを使用すると、多くの例外を処理したり、関数の署名に追加したりする必要があります。

たとえばSpringで提案されたJavaのプログラミング・モデルは、透過的に例外を処理することです。サービス用のインターフェースがあり、実装では WebService、SQL データベースなどを使用できます。どの例外をどのように処理する必要があるかをどのように知ることができますか? したがって、単一の場所で処理できる独自の例外階層を提供します。

Spring はまた、すべての例外を でラップしますNestedRuntimeException。

アスペクトまたはフィルターで例外を処理することもできます。その場合、例外はビジネス コードに対して完全に透過的である必要があります。通常の処理から例外処理を完全に分離します。

于 2013-05-19T10:50:41.830 に答える