Наконец, блок без выгоды блокирует антишаблон Java?

Я думаю, что попытка без выгоды является антишаблоном. Используя попытку/выгоду обработать исключительный условия (файл ошибки IO, тайм-аут сокета, и т.д.) не антишаблон.

при использовании попытки/наконец очистки рассмотрите блок использования вместо этого.

try {
    doSomeStuff()
    doMore()
} catch (Exception e) {
    log.error(e);
} finally {
   doSomeOtherStuff()
}

не делают этого ни один... Вы просто скрыли больше ошибок (хорошо не точно скрытый их..., но мешал иметь дело с ними. При ловле Исключения, Вы также ловите любой вид RuntimeException (как NullPointer и ArrayIndexOutOfBounds).

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

Я использую попытку/наконец в следующей форме:

try{
   Connection connection = ConnectionManager.openConnection();
   try{
       //work with the connection;
   }finally{
       if(connection != null){
          connection.close();           
       }
   }
}catch(ConnectionException connectionException){
   //handle connection exception;
}

я предпочитаю это попытке/выгоде/наконец (+ вложенная попытка/выгода в наконец). Я думаю, что это более кратко, и я не копирую выгоду (Исключение).

По-моему, больше имеет место, что finally с catch указывают на некоторую проблему. Идиома ресурса очень проста:

acquire
try {
    use
} finally {
    release
}

В Java у Вас может быть исключение из в значительной степени где угодно. Часто получать броски контролируемая исключительная ситуация, разумный способ обработать, который должен поместить выгоду вокруг как партия. Не пробуйте некоторую отвратительную пустую проверку.

, Если Вы собирались быть действительно анальными, необходимо отметить, что существуют подразумеваемые приоритеты среди исключений. Например, ThreadDeath должен ударить все, прибывает ли он из, получают/используют/выпускают. Обработка этих приоритетов правильно неприглядна.

Поэтому абстрагируют Ваш ресурс, обрабатывающий далеко с Выполнением Вокруг идиомы.

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

Одна вещь я делаю, когда контакт с дескрипторами файлов (для записи) сбрасывает поток прежде, чем закрыть ее с помощью метода IOUtils.closeQuietly, который не выдает исключения:

OutputStream os = null;
OutputStreamWriter wos = null;
try { 
   os = new FileOutputStream(...);
   wos = new OutputStreamWriter(os);
   // Lots of code

   wos.flush();
   os.flush();
finally {
   IOUtils.closeQuietly(wos);
   IOUtils.closeQuietly(os);
}

мне нравится делать его тот путь по следующим причинам:

• не абсолютно безопасно проигнорировать исключение при закрытии файла - если существуют байты, которые еще не были записаны в файл, тогда файл не может быть в состоянии, которое ожидала бы вызывающая сторона;
• Так, если исключение повышено во время сброса () метод, это будет распространено вызывающей стороне, но я все еще удостоверюсь, что все файлы закрываются. Метод IOUtils.closeQuietly (...) является менее подробным тогда соответствующая попытка..., ловит... игнорируют меня блок;
• При использовании нескольких потоков вывода порядок на сброс () метод важен. Потоки, которые были созданы путем передачи других потоков как конструкторов, должны быть сброшены сначала. То же самое допустимо для завершения () метод, но сброс () более ясен, по-моему.

Нет абсолютно ничего неправильно попытки с наконец и никакая выгода. Рассмотрите следующее:

InputStream in = null;
try {
    in = new FileInputStream("file.txt");
    // Do something that causes an IOException to be thrown
} finally {
    if (in != null) {
         try {
             in.close();
         } catch (IOException e) {
             // Nothing we can do.
         }
    }
}

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

Нисколько.

Что случилось код в наконец.

Помнят, что наконец будет всегда выполняться и просто опасен (поскольку Вы только что засвидетельствовали) помещать что-то, что может выдать исключение там.

Я думаю, что реальный "антишаблон" здесь делает что-то в finally блок, который может бросить, не не имея выгоды.

Я сказал бы, что блок попытки без блока выгоды является антишаблоном. Высказывание "Не имеет наконец без выгоды", подмножество, "Не имеют попытки без выгоды".

Попробуйте / наконец-то - это способ правильно освободить ресурсы. Код в блоке finally НИКОГДА не должен бросать вызов, поскольку он должен действовать только на ресурсы или состояние, которые были получены ДО входа в блок try.

В стороне, я думаю, что log4J почти анти- шаблон.

ЕСЛИ ВЫ ХОТИТЕ ПРОВЕРИТЬ РАБОЧУЮ ПРОГРАММУ, ИСПОЛЬЗУЙТЕ ПОДХОДЯЩИЙ ИНСТРУМЕНТ ИНСПЕКЦИИ (то есть отладчик, IDE или, в крайнем случае, ткач байтового кода, но НЕ РАЗМЕЩАЙТЕ ЗАЯВЛЕНИЯ О ЛОГИНГЕ НА КАЖДЫХ НЕСКОЛЬКИХ СТРОКАХ!).

два примера, которые вы представляете, первый выглядит правильным. Второй включает код регистратора и вносит ошибку. Во втором примере вы подавляете исключение, если оно вызывается первыми двумя операторами (т.е. вы его ловите и регистрируете, но не генерируете повторно. Это то, что я нахожу очень распространенным при использовании log4j, и представляет собой настоящую проблему при разработке приложений. В основном с вашим изменением вы заставляете программу терпеть неудачу таким образом, что системе было бы очень сложно обработать, поскольку вы в основном продвигаетесь вперед, как будто у вас никогда не было исключения (вроде как VB basic при ошибке возобновляет следующую конструкцию).