Java io ужасная попытка наконец блок

В общем, в IOUtils есть несколько методов closeQuietly .

Вы можете реализовать служебный метод:

public final class IOUtil {
  private IOUtil() {}

  public static void closeQuietly(Closeable... closeables) {
    for (Closeable c : closeables) {
        if (c != null) try {
          c.close();
        } catch(Exception ex) {}
    }
  }
}

Тогда ваш код будет сокращен до:

try {
  copy(in, out);
} finally {
  IOUtil.closeQuietly(in, out);
}

Дополнительно

Я полагаю, что такой метод будет в сторонней библиотеке с открытым исходным кодом. Однако я предпочитаю избегать ненужных зависимостей библиотеки, если я не использую большую часть ее функциональных возможностей. Поэтому я сам стараюсь реализовать такие простые служебные методы.

В большинстве случаев исключение 'in' close () не имеет значения, поэтому:

    try {
      copy(in, out);
    } finally {
    try {  in.close()  }  catch (Exception e) { /* perhaps log it */ }
    try {  out.close() }  catch (Exception e) {/* perhaps log it */ }
    } 

Обычно проглатывание исключений - плохая практика, но в этом случае я думаю, это нормально.

try {
    final InputStream in = new FileInputStream(inputFileName);
    try {
        final OutputStream out = new FileOutputStream(outputFileName);    
        try {
            copy(in, out);
            out.flush(); // Doesn't actually do anything in this specific case.
        } finally {
            out.close();
        }
    } finally {
        in.close();
    }
} catch (IOException exc) {
    throw new SomeRelevantException(exc);
}

Помните, что открытие потока может вызвать исключение, поэтому вам нужно попытаться между открытием потока (пожалуйста, не делайте какой-то хак с использованием null s. Все может вызвать ошибку (которые не являются экземплярами Exception ).

Оказывается, что catch и , наконец, должны редко использовать один и тот же try .

Начиная с Java SE 7, вы можете писать, используя try-with-resource, чтобы избежать такого большого отступа. Это более или менее делает то же самое, хотя есть скрытые подавленные исключения.

try (
    final InputStream in = new FileInputStream(inputFileName);
    final OutputStream out = new FileOutputStream(outputFileName);    
) {
    copy(in, out);
    out.flush(); // Doesn't actually do anything in this specific case.
} catch (IOException exc) {
    throw new SomeRelevantException(exc);
}

Вы можете использовать идиому Execute Around .

Я считаю, что стандартным хорошим способом копирования является использование NIO transferTo / transferFrom .

Я твердо уверен, что в Java 7.0 вам больше не нужно явно закрывать поток самостоятельно. Возможности языка в Java 7

try (BufferedReader br = new BufferedReader(new FileReader(path)) {
   return br.readLine();
}

Одна уловка, которую я иногда использую, - это определение метода под названием closeQuietly (Closeable) который проверяет, является ли его аргумент нулевым , а затем закрывает его, игнорируя любые исключения. Но вам нужно быть осторожным, закрывая OutputStreams и Writers таким образом, потому что они могут фактически вызвать исключение, которое имеет значение ; например если окончательный флеш не удастся.

С Java 7 ситуация, вероятно, улучшится. Сообщается, что в ней будет новая конструкция, обеспечивающая более сжатый способ обработки управляемых ресурсов; например потоки, которые необходимо закрыть по завершении работы.

Наконец, вы должны знать, что в вашем примере есть ошибка. Если вызов метода открывает второй поток, первый поток не будет закрыт. Второе открытие нужно сделать внутри блока try .

Guava имеет очень хорошие API ввода-вывода, которые устраняют необходимость в этом.Например, ваш пример:

Files.copy(new File(inputFileName), new File(outputFileName));

В более общем плане он использует концепцию InputSupplier s и OutputSupplier s, чтобы разрешить InputStream s и ] OutputStream должны быть созданы в его служебных методах, что дает ему полный контроль над ними, чтобы он мог правильно обрабатывать закрытие.

Кроме того, у него есть Closeables.closeQuietly (Closeable) , который, по сути, является типом метода, предложенного в большинстве ответов.

Средства ввода-вывода в нем все еще находятся в стадии бета-тестирования и могут быть изменены, но их стоит проверить и даже использовать, в зависимости от того, над чем вы работаете.