1

ディスク上のファイルを管理し、レポートを xml 形式で保存するクラスがあります。JAXB を使用するため (ただし、他の xml ライブラリを使用できますが、関連性はありません)、jaxb (または他の xml ライブラリ) チェック例外を生成する可能性があります。
カプセル化を維持するために、元のライブラリの例外をライブラリの論理レベルで「変換」する必要があります。しかし、関連性の低いクラスがほとんどなく、クラスの数をあまり増やしたくありません。ファイル関連のクラスなので、その場合は IOException で十分だと思います。

public void save(File file) throws IOException {
    try{
        JAXBContext jc = JAXBContext.newInstance(ArchiveInfo.class);
        Marshaller m = jc.createMarshaller();
        m.marshal(this, file);
    } catch (JAXBException jexc) {
        throw new IOException(jexc);
    }
}
  1. この解決策に同意しますか?単純さと正確さの間の適切なトレードオフですか?
  2. 適切な例外を見つけたので、幸運でした。そうでない場合は、例外クラスを使用するのは適切な設計ではないため、必然的に独自の例外を定義します。(呼び出し元に Exception をキャッチさせ、暗黙的に RuntimeException もキャッチします)。実行時例外はRuntimeExceptionクラスで共通の祖先を持つのに対し、すべてのチェック例外は持たないのは、例外の構造上の異常ではないでしょうか?
4

1 に答える 1

2

1）私はあなたに同意し、同じことをする傾向があります。多くの例外タイプを手動で保持することは、ほとんどの場合役に立ちません。アプリの上位レベルで必要なのは、ユーザーに意味のあるエラーを提供できる十分な精度です。あなたの場合、「ファイルを読み取れませんでした」ため、IOException は問題ありません。

2) はい、これは長い間文書化されてきた Java の例外メカニズムの欠陥です... Java の例外メカニズムには根本的な欠陥があるとさえ言う人もいます (ほとんどの場合、チェック例外は誤用されています)。とにかくあなたの場合、私は時々キャッチイットオールInvalidStateExceptionまたはIllegalArgumentExceptionを使用します。もちろん、より正確な意味をアプリの上位レイヤーに伝える必要がある場合は、いつでも独自の例外を作成できます。しかし、覚えておいてください:キス:)

于 2011-05-30T15:55:54.220 に答える