web-dev-qa-db-ja.com

ネストされたtry / catchブロックの設定はありますか？

Javaでのリーダーとストリームの使用について常に私を悩ませていることの1つは、close()メソッドが例外をスローする可能性があることです。closeメソッドを配置することは良いアイデアなので、 finallyブロックでは、少し厄介な状況が必要になります。通常、この構造を使用します。

FileReader fr = new FileReader("SomeFile.txt");
try {
    try {
        fr.read();
    } finally {
        fr.close();
    }
} catch(Exception e) {
    // Do exception handling
}

しかし、私はこの構造も見ました：

FileReader fr = new FileReader("SomeFile.txt");
try {
    fr.read() 
} catch (Exception e) {
    // Do exception handling
} finally {
    try {
        fr.close();
    } catch (Exception e) {
        // Do exception handling
    }
}

キャッチブロックが1つしかなく、よりエレガントに見えるので、最初の構造を好みます。 2番目または別の構造を実際に好む理由はありますか？

更新：readとcloseの両方がIOExceptionsのみをスローすることを指摘した場合、違いはありますか？したがって、読み取りが失敗すると、同じ理由でクローズが失敗するように思われます。

javatry-catch
41
eaolson

私はいつも最初の例に行きます。

Closeが例外をスローする場合（実際にはFileReaderでは発生しません）、呼び出し元に適切な例外をスローするための標準の処理方法ではないでしょうか。近い例外は、ほぼ確実に、リソースを使用していたすべての問題に優先します。例外処理の考えがSystem.err.printlnを呼び出すことである場合は、おそらく2番目の方法がより適切です。

例外をどこまでスローするかという問題があります。 ThreadDeathは常に再スローされる必要がありますが、finally内の例外はそれを停止します。同様に、Errorは、RuntimeExceptionおよびRuntimeExceptionよりも、チェックされた例外よりもスローする必要があります。本当にしたい場合は、これらのルールに従うコードを記述して、「実行」イディオムで抽象化できます。

7
Tom Hawtin - tackline

最初の例には大きな問題があると思います。つまり、読み取り時または読み取り後に例外が発生すると、finallyブロックが実行されます。ここまでは順調ですね。しかし、fr.close()が原因で別の例外がスローされるとどうなりますか？これは最初の例外（returnをfinallyブロックに入れるようなもの）と「トランプ」し、実際に問題を引き起こした原因に関するすべての情報が失われます開始と。

あなたのfinallyブロックは使用する必要があります：

IOUtil.closeSilently(fr);

このユーティリティメソッドは次のことを行います。

public static void closeSilently(Closeable c) {
    try { c.close(); } catch (Exception e) {} 
}
26
oxbow_lakes

私は2番目のものを好みます。どうして？ read()とclose()の両方が例外をスローした場合、それらの1つが失われる可能性があります。最初の構成では、close()からの例外がread()からの例外をオーバーライドし、2番目の構成ではclose()からの例外が個別に処理されます。

Java 7以降、 try-with-resources構文 を使用すると、これがはるかに簡単になります。例外を気にせずに読むには：

try (FileReader fr = new FileReader("SomeFile.txt")) {
    fr.read();
    // no need to close since the try-with-resources statement closes it automatically
}

例外処理あり：

try (FileReader fr = new FileReader("SomeFile.txt")) {
    fr.read();
    // no need to close since the try-with-resources statement closes it automatically
} catch (IOException e) {
    // Do exception handling
    log(e);
    // If this catch block is run, the FileReader has already been closed.
    // The exception could have come from either read() or close();
    // if both threw exceptions (or if multiple resources were used and had to be closed)
    // then only one exception is thrown and the others are suppressed
    // but can still be retrieved:
    Throwable[] suppressed = e.getSuppressed(); // can be an empty array
    for (Throwable t : suppressed) {
        log(suppressed[t]);
    }
}

Try-catchは1つだけ必要であり、すべての例外を安全に処理できます。必要に応じてfinallyブロックを追加できますが、リソースを閉じる必要はありません。

3
Michael Myers

readとcloseの両方が例外をスローした場合、readはオプション1で非表示になります。そのため、2番目のオプションはより多くのエラー処理を行います。

ただし、ほとんどの場合、最初のオプションが優先されます。

  1. 多くの場合、生成されたメソッドで例外を処理することはできませんが、その操作内でストリーム処理をカプセル化する必要があります。
  2. コードにライターを追加して、2番目のアプローチがどのように冗長になるかを確認してください。

生成されたすべての例外を渡す必要がある場合は、 それが可能 です。

2
McDowell

私が見る限り、違いは、さまざまなレベルでさまざまな例外と原因が関係していることです。

キャッチ（例外e）

それを覆い隠す。複数のレベルの唯一のポイントは、例外を区別し、それらに対して何をするかです。

try
{
  try{
   ...
  }
   catch(IOException e)
  {
  ..
  }
}
catch(Exception e)
{
  // we could read, but now something else is broken 
  ...
}
1
Steve B.

私は通常、次のことを行います。まず、try/catchの混乱に対処するためのテンプレートメソッドベースのクラスを定義します。

import Java.io.Closeable;
import Java.io.IOException;
import Java.util.LinkedList;
import Java.util.List;

public abstract class AutoFileCloser {
    private static final Closeable NEW_FILE = new Closeable() {
        public void close() throws IOException {
            // do nothing
        }
    };

    // the core action code that the implementer wants to run
    protected abstract void doWork() throws Throwable;

    // track a list of closeable thingies to close when finished
    private List<Closeable> closeables_ = new LinkedList<Closeable>();

    // mark a new file
    protected void newFile() {
        closeables_.add(0, NEW_FILE);
    }

    // give the implementer a way to track things to close
    // assumes this is called in order for nested closeables,
    // inner-most to outer-most
    protected void watch(Closeable closeable) {
        closeables_.add(0, closeable);
    }

    public AutoFileCloser() {
        // a variable to track a "meaningful" exception, in case
        // a close() throws an exception
        Throwable pending = null;

        try {
            doWork(); // do the real work

        } catch (Throwable throwable) {
            pending = throwable;

        } finally {
            // close the watched streams
            boolean skip = false;
            for (Closeable closeable : closeables_) {
                if (closeable == NEW_FILE) {
                    skip = false;
                } else  if (!skip && closeable != null) {
                    try {
                        closeable.close();
                        // don't try to re-close nested closeables
                        skip = true;
                    } catch (Throwable throwable) {
                        if (pending == null) {
                            pending = throwable;
                        }
                    }
                }
            }

            // if we had a pending exception, rethrow it
            // this is necessary b/c the close can throw an
            // exception, which would remove the pending
            // status of any exception thrown in the try block
            if (pending != null) {
                if (pending instanceof RuntimeException) {
                    throw (RuntimeException) pending;
                } else {
                    throw new RuntimeException(pending);
                }
            }
        }
    }
}

「保留中の」例外に注意してください。これは、クローズ中にスローされた例外が、本当に気になる可能性のある例外をマスクする場合に対応します。

は最後に装飾されたストリームの外側から最初に閉じようとするため、FileWriterをラップしているBufferedWriterがある場合は、最初にBuffereredWriterを閉じようとし、それが失敗した場合でも、FileWriter自体を閉じようとします。

上記のクラスは次のように使用できます。

try {
    // ...

    new AutoFileCloser() {
        @Override protected void doWork() throws Throwable {
            // declare variables for the readers and "watch" them
            FileReader fileReader = null;
            BufferedReader bufferedReader = null;
            watch(fileReader = new FileReader("somefile"));
            watch(bufferedReader = new BufferedReader(fileReader));

            // ... do something with bufferedReader

            // if you need more than one reader or writer
            newFile(); // puts a flag in the 
            FileWriter fileWriter = null;
            BufferedWriter bufferedWriter = null;
            watch(fileWriter = new FileWriter("someOtherFile"));
            watch(bufferedWriter = new BufferedWriter(fileWriter));

            // ... do something with bufferedWriter
        }
    };

    // .. other logic, maybe more AutoFileClosers

} catch (RuntimeException e) {
    // report or log the exception
}

このアプローチを使用すると、ファイルのクローズを再度処理するために、try/catch/finallyについて心配する必要はありません。

これが重すぎて使用できない場合は、少なくとも、try/catchおよびそれが使用する「保留中」変数のアプローチに従うことを検討してください。

1
Scott Stanchfield

場合によっては、入れ子になったTry-Catchが避けられないことがあります。たとえば、エラー回復コード自体が例外をスローする可能性がある場合。ただし、コードを読みやすくするために、ネストされたブロックを独自のメソッドにいつでも抽出できます。ネストされたTry-Catch-Finallyブロックのその他の例については、 this ブログ投稿を確認してください。

0
codelion

@Chris Marshallのアプローチは好きですが、例外が黙って飲み込まれるのを見たくありません。特に例外なく継続している場合は、例外をログに記録するのが最善だと思います。

私は常にこの種の一般的な例外を処理するためにユーティリティクラスを使用しますが、これを彼の答えとは少し異なります。

私は常にロガー（私にとってはlog4j）を使用してエラーなどを記録します。

IOUtil.close(fr);

ユーティリティメソッドを少し変更します。

public static void close(Closeable c) {
    try {
      c.close();
    } catch (Exception e) {
      logger.error("An error occurred while closing. Continuing regardless", e); 
    } 
}
0
Dunderklumpen

私が使用する標準的な規則は、例外をfinallyブロックからエスケープさせてはならないということです。

これは、例外が既に伝搬している場合、finallyブロックからスローされた例外が元の例外より優先される（したがって失われる）ためです。

99％の場合、元の例外が問題の原因である可能性があるため、これは望ましいことではありません（二次的な例外は最初の例外の副作用である可能性がありますが、元の例外の原因を見つけることができなくなるため、実際の問題）。

したがって、基本的なコードは次のようになります。

try
{
    // Code
}
// Exception handling
finally
{
    // Exception handling that is garanteed not to throw.
    try
    {
         // Exception handling that may throw.
    }
    // Optional Exception handling that should not throw
    finally()
    {}
}
0
Martin York

2番目のアプローチ。

そうでなければ、FileReaderコンストラクターからの例外をキャッチしているようには見えません。

http://Java.Sun.com/j2se/1.5.0/docs/api/Java/io/FileReader.html#FileReader（Java.lang.String）

public FileReader（String fileName）がFileNotFoundExceptionをスローする

そのため、通常、tryブロック内にもコンストラクタがあります。最後のブロックでは、リーダーがnullでないかどうかを確認してから、クローズを試みます。

同じパターンがDatasource、Connection、Statement、ResultSetにも当てはまります。

0
anjanb

ネストされたtry-catchが優先されない場合があります。これを考慮してください。

try{
 string s = File.Open("myfile").ReadToEnd(); // my file has a bunch of numbers
 // I want to get a total of the numbers 
 int total = 0;
 foreach(string line in s.split("\r\n")){
   try{ 
     total += int.Parse(line); 
   } catch{}
 }
catch{}

これはおそらく悪い例ですが、入れ子のtry-cactchが必要になる場合があります。

0
Haoest