ローカライズされた例外を処理する方法は？

Question

私は、呼び出し元に再スローすることなく例外を処理する方法を正確にはわからない十字路にいつも来ているようです。

以下の状況を処理するより良い方法はありますか？

private DataHandler retrieveFromGridFS(ObjectId id) throws IOException 
{ 
    GridFS gridFS = new GridFS(getDBReference());   
    GridFSDBFile out = gridFS.find(id); 

    File temp = File.createTempFile(
      (String)out.getMetaData().get("productName"), 
      (String)out.getMetaData().get("productType")); 

    out.writeTo(temp); 

    return new DataHandler(new FileDataSource(temp));   
} 

上記private方法はIOExceptionを投げることができます。

そうよう、この方法を利用して：私はnullを返す危険性がないように、私は再スローをするように強制してい

public DataHandler retrieveProduct(String productId) throws IOException 
{ 
    ObjectId id = new ObjectId(productId); 
    DataHandler handler = null; 

    try 
    { 
     handler = retrieveFromGridFS(id); 
    } 
    catch(IOException ex) 
    { 
     logger.error(ex); 
     throw new IOException("A problem occurred retrieving product."); 
    } 

    return handler; 
} 

。

Answer 1

完全に依存します。

具体的には、IOExceptionを上位層に浸透させたいのですか、またはアプリケーション固有の例外で下位層で発生する可能性のあるさまざまな例外をカプセル化しますか？

この例外から回復する必要がありますか？そうでない場合はRuntimeExceptionがより適切ですか？ （あなたがを行う場合でも、あなたは、高レベルの宣言型の例外処理のために提供する環境で動作している、回収可能例外が必要？）

はそれがより理にかなって返す避けるためにNullObjectパターンを使用しますヌル？

（等:)

Answer 2

は、一般的に、あなたがを発生したイベントに応答することができた場合に例外をキャッチし、話します。 Ex。失敗したときに接続を再試行するコードがあるとしましょう。その後、IOExceptionをキャッチしてx回再試行するループが発生する可能性があります。上記の呼び出し元は、根本的な失敗を気にしません。

例外が発生して処理できない場合は、そうではありません。本質的にあなたは駄目を過ごしています。

最近、ほとんどの場合、他の人が対象とするように、例外の再発行を避ける傾向がありました。私は経験を通してそれがほとんどの時間価値を実際に加えていないことを発見しました。

Answer 3

何ですか？ retrieveProductは、retrieveFromGridFSが何をしても、ObjectIdではなく識別子としてStringを使うだけの便利な機能です。それで、例外のセットをretrieveFromGridFSと同じにすることはできませんか？