Как наиболее элегантно окружить код командой try / catch

Есть еще один вариант, если обработка исключений не обязательно должна происходить в методе getContents - добавить к методу предложение throws, чтобы метод генерировал исключение:

public static String getContents (File file)
    throws IOException, FileNotFoundException {

Таким образом, код, вызывающий метод, будет обрабатывать Exceptions, а не сам метод. В этом методе не будет необходимости в блоках _5 _ / _ 6_, если Exception будут переданы методам, которые его вызвали.

Это может быть или не быть желаемым способом справиться с ситуацией, в зависимости от ожидаемого поведения метода.

Изменить

Если подумать, то хорошей идеей может быть создание исключения из метода. Я думаю, что комментарий Д. Шоули, на мой взгляд, хорошо подытоживает: «обработка исключений должна означать обработку исключения только там, где это имеет смысл».

В этом случае кажется, что метод getContents получает содержимое указанного File и возвращает String вызывающей стороне.

Если обработка исключений должна была выполняться в методе getConents, единственный способ сообщить, что произошла ошибка, - это вернуть какое-то заранее определенное значение, например null, вызывающему, чтобы сообщить, что произошла ошибка.

Однако, если сам метод возвращает исключение вызывающей стороне, вызывающая сторона может выбрать соответствующую реакцию:

try {
    String contents = getContents(new File("input.file"));
} catch (IOException ioe) {
    // Perform exception handling for IOException.
} catch (FileNotFoundException fnfe) {
    // Inform user that file was not found.
    // Perhaps prompt the user for an alternate file name and try again?
}

Вместо того, чтобы метод setContents предлагал свой собственный протокол для уведомления о возникновении ошибки, вероятно, было бы лучше передать IOException и FileNotFoundException обратно вызывающей стороне метода, чтобы обработка исключений могла выполняться в месте, где соответствующий альтернативный действия могут иметь место.

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

Вы можете справиться с этим следующим образом:

StringBuilder contents = new StringBuilder();
BufferedReader reader;

try {
   reader = new BufferedReader(new FileReader(file));

   while (reader.ready()) {
      contents.append(reader.readLine());
   }

} catch (FileNotFoundException fne) {
   log.warn("File Not Found", fne);
} catch (IOException ioe) {
   log.warn("IOException", ioe);
} 

return contents.toString();

Вам, вероятно, следует использовать StringBuilder в приведенном выше случае вместо String, что намного лучше с точки зрения производительности.

public static String getContents (File file) {
    String contents = new String();
    BufferedReader reader = null;
    try {
        reader = new BufferedReader(new FileReader(file));
        while (reader.ready())
            contents += reader.readLine();
    }
    catch (FileNotFoundException ex) {
        // handle FileNotFoundException
    }
    catch (IOException ex) {
        // handle IOException
    }
    finally {
        if (reader != null) {
            try {
                reader.close();
            }
            catch (IOException ex) {
                // handle IOException
            }
        }
    }
    return contents;
}

Я добавил блок finally, чтобы закрыть ваш BufferedReader, хотя вы не сделали этого в своем коде. Я также предлагаю вам использовать StringBuilder вместо String конкатенации, но кто-то уже указал на это. Объявление и инициализация reader находится за пределами блока try только из-за добавленного мной блока finally; в противном случае ссылка reader могла быть объявлена ​​внутри блока try.

и я не обрабатывал исключения, я не думал, что это связано с вашим вопросом.

Вы можете попробовать переместить оператор return в блок finally.

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

Что касается оператора return, то, если вы воспользуетесь моим предложением выше, вы можете просто вернуться после блока try / catch.

Поэтому, если бы я использовал нулевое возвращаемое значение, чтобы указать на ошибку, я бы сделал

public static String getContents (File file) {
    String contents = null;
    try {        
        BufferedReader reader = new BufferedReader(new FileReader(file));
        contents = new String();
        while (reader.ready())
            contents += reader.readLine();
    } catch (Exception e) {
        // Error Handling
    }
    return contents;
}

Здесь вам не хватает простой утилиты, которая значительно упрощает очистку:

public static void closeAndLog(Closable c) {
    if ( c == null )
        return;

    try { 
        c.close() 
    } catch ( IOException e) {
        LOGGER.warn("Failed closing " + c +, e);
    }
}

Таким образом, ваш код может стать:

public static String getContents (File file) throws IOException {

    BufferedReader r = null;

    try { 
        r = new BufferedReader(...);
        // do stuff
    } finally {
        closeAndLog(r);
    }
}

IMHO у вас есть два способа правильно справиться с исключениями (здесь IOException и FileNotFoundException):

• вы просто бросаете его, поэтому вызывающий должен иметь дело с этим, но в ответе есть подробная причина сбоя и поэтому может выбрать наиболее подходящее поведение
• вы встраиваете оба возможных исключения только в одно из своих, которые выражают «что-то пошло не так», поэтому вызывающий абонент должен иметь дело только с одним исключением (но сообщение конечного пользователя, вероятно, будет менее острым)

Чтобы получить полезный совет по поводу исключений, см. Также: Почему люди, использующие Java, часто молча потребляют исключения ?

Начиная с Java 7, вы можете использовать try-with-resources для убедитесь, что ваши ресурсы закрываются правильно и «автоматически». Все, что вам нужно, это объект, реализующий java.lang.AutoCloseable, который делает BufferedReader. На самом деле в документации есть следующий пример:

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