2

xsd に対して xml を検証していますが、例外を処理する必要がある場合が多いことがわかりました。

これらはJavaでチェック例外と呼ばれていると思いますか?

SchemaFactory sf = ....

Schema schema = sf.newSchema(...)    // SAXException has to be handled
Validator validator = ...

validator.validate(xmlFile);   // IOException has to be handled again

このコード ブロックはどのように記述すればよいですか?

try/catch 内にネストされた try/catch を使用しますか?

4

3 に答える 3

2 
try {
  SchemaFactory sf = ....

  Schema schema = sf.newSchema(...)    // SAXException has to be handled
  Validator validator = ...

  validator.validate(xmlFile);   // IOException has to be handled again
} catch (SAXException e) {
    // handle SAX error
} catch (IOException e) {
    // handle IO error
}
于 2011-11-26T15:23:23.470 に答える
0

実際には、回復戦略がない場合は、チェック済み例外を処理することは想定されていません。

使用しているスキーマが Sax 例外を発生させた場合に備えて、別のスキーマがありますか? 使用しているバリデーターが IO 例外を発生させた場合に備えて、別のバリデーターを持っていますか? これらの例外に対して可能な他の回復はありますか?

そうしない場合は、おそらくその例外をランタイム (チェックされていない) 例外内にラップし、最上位レイヤー (キャッチされる場所) にスローする必要があります。最終的に、問題を理解するために必要な場合は、ラッパー クラスにメッセージを追加できます。

この sax スキーマがなくてもプログラムが正しく動作する場合 (この場合、実行時例外をキャッチできるように Exception をキャッチする場合)、またはプログラムに回復戦略がない限り、再スローせずに例外をキャッチすることは想定されていません。

回復戦略が失敗した場合は、回復例外を未チェックの例外にラップして、最上位レイヤーで処理できるようにすることもできます (ログ + エラー 500 など)。

これがフェイルファストの原則です。

Java では、チェックされた例外とチェックされていない例外について、何年にもわたって存在する大きな論争があることに注意してください。Java に影響力のある多くの人々は、チェック例外の導入は間違いだったと本当に考えています。

主な理由は次のとおりです。

  • 人々は怠け者であり、間違った場所で例外をキャッチする傾向があるため、もう気にする必要はありません。

  • 人々は太陽の勧告に従わず、API のクライアント側のコンパイル時に「警告を発する」ためだけにチェック例外をスローします。

  • 人々は、チェックされた例外を宣言するメソッドだけが例外を発生させることができ、どのコード/メソッドも例外をスローできると考える傾向があります。コンパイラがそう言った場合にのみ例外をキャッチすることは想定されていません。どこでキャッチするのが適切かを考える必要があります。

ブルース・エッケルにちょっと同意:

問題は、これが心理学の分野に分類される言語設計者として私たちが行っている検証されていない仮定であることだと思います。

そのテーマに関する多くのリンクを見つけることができます。多くの Java 開発者はこれを認識していませんが、多くの成熟したフレームワークは現在、主に未チェックの例外 (Spring、EJB3...) を使用しています。

また、C# (チェック例外なし) や Java を使用している人は、チェック例外がない方が良いと考える傾向があります。

だからあなたはするかもしれません：

try {
    your code here
} catch (Exception e) {
    throw new RuntimeException("optionnal message",e);
}

役に立つと思われる場合は、最終的にカスタム ランタイム例外を使用できます。

太陽の源:

http://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html

肝心なガイドラインは次のとおりです。クライアントが例外から回復することが合理的に期待できる場合は、それをチェック済み例外にします。クライアントが例外から回復するために何もできない場合は、それを非チェック例外にします。

http://docs.oracle.com/javase/specs/jls/se5.0/html/exceptions.html#11.5

クラス Exception は、通常のプログラムが回復したいすべての例外のスーパークラスです。

Bruce Eckel (Java で考える本): http://www.mindview.net/Etc/Discussions/CheckedExceptions

前の段落の「無視できる」は、別の問題です。理論的には、コンパイラーがプログラマーに例外を処理するか、例外仕様でそれを渡すように強制すると、プログラマーの注意は常にエラーの可能性に戻され、適切に処理されるというものです。問題は、これが心理学の分野に分類される言語設計者として私たちが行っている検証されていない仮定であることだと思います。私の理論では、誰かが何かをしようとしていて、あなたが常に迷惑をかけているとき、彼らは利用可能な最速のデバイスを使用してそれらの迷惑を解消し、おそらく彼らが戻って取りかかると仮定して、自分のことを成し遂げることができます.後でデバイスを取り出します。

...
} catch (SomeKindOfException e) {}
于 2011-11-26T17:16:58.697 に答える
0

try/catch 内にネストされた try/catch を使用しますか?

IMO、いいえ。

try {
    //...
} catch(SAXException e) {
    //handle SAXException
} catch(IOException e) {
    //handle IOException
}

ネストされた try/catch よりもコードがきれいに見えると思います。

このコード ブロックはどのように記述すればよいですか?

その場で例外を処理する必要があるか (その場合は を使用するか)、または呼び出し側で例外を処理する必要があるかどうか (その場合は、句try/catchを使用して呼び出し側に伝搬する必要があるかどうか) によって異なります。throws

public void validateXml() throws SAXException, IOException {
    //...
于 2011-11-26T15:53:25.540 に答える