кидає виняток, нарешті, блокує

Чи є елегантний спосіб поводження з винятками, які кидаються в finallyблок?

Наприклад:

try {
  // Use the resource.
}
catch( Exception ex ) {
  // Problem with the resource.
}
finally {
   try{
     resource.close();
   }
   catch( Exception ex ) {
     // Could not close the resource?
   }
}

Як уникнути try/ catchв finallyблоці?

Я зазвичай роблю так:

try {
  // Use the resource.
} catch( Exception ex ) {
  // Problem with the resource.
} finally {
  // Put away the resource.
  closeQuietly( resource );
}

В іншому місці:

protected void closeQuietly( Resource resource ) {
  try {
    if (resource != null) {
      resource.close();
    }
  } catch( Exception ex ) {
    log( "Exception during Resource.close()", ex );
  }
}

Зазвичай я використовую один із closeQuietlyметодів у org.apache.commons.io.IOUtils:

public static void closeQuietly(OutputStream output) {
    try {
        if (output != null) {
            output.close();
        }
    } catch (IOException ioe) {
        // ignore
    }
}

Якщо ви використовуєте Java 7 та resourceдодатки AutoClosable, ви можете це зробити (використовуючи InputStream як приклад):

try (InputStream resource = getInputStream()) {
  // Use the resource.
}
catch( Exception ex ) {
  // Problem with the resource.
}

Можливо, трохи вгорі, але, можливо, корисно, якщо ви дозволяєте виняткам пузирятись, і ви не можете нічого ввійти в межах свого методу (наприклад, тому що це бібліотека, і ви краще дозволите коду виклику обробляти винятки та вести журнал):

Resource resource = null;
boolean isSuccess = false;
try {
    resource = Resource.create();
    resource.use();
    // Following line will only run if nothing above threw an exception.
    isSuccess = true;
} finally {
    if (resource != null) {
        if (isSuccess) {
            // let close throw the exception so it isn't swallowed.
            resource.close();
        } else {
            try {
                resource.close();
            } catch (ResourceException ignore) {
                // Just swallow this one because you don't want it 
                // to replace the one that came first (thrown above).
            }
        }
    }
}

ОНОВЛЕННЯ: Я трохи більше переглянув це питання і знайшов чудову публікацію в блозі від того, хто чітко думав про це більше, ніж я: http://illegalargumentexception.blogspot.com/2008/10/java-how-not-to-make -mess-of-stream.html Він іде на крок далі і поєднує два винятки в одне, що я можу вважати корисним у деяких випадках.

Як і в Java 7, вам більше не потрібно явно закривати ресурси в остаточному блоці, натомість ви можете використовувати синтаксис спробувати -with-ресурси. Оператор "спробу використання ресурсів" - це тест, який оголошує один або кілька ресурсів. Ресурс - це об'єкт, який необхідно закрити після закінчення програми з ним. Оператор спробу використання ресурсів забезпечує закриття кожного ресурсу в кінці оператора. Будь-який об'єкт, який реалізує java.lang.AutoCloseable, який включає всі об'єкти, які реалізують java.io.Closeable, може використовуватися як ресурс.

Припустимо наступний код:

try( Connection con = null;
     Statement stmt = con.createStatement();
     Result rs= stmt.executeQuery(QUERY);)
{  
     count = rs.getInt(1);
}

Якщо трапиться якийсь виняток, метод закриття буде викликаний на кожному з цих трьох ресурсів у зворотному порядку, в якому вони були створені. Це означає, що метод закриття буде викликаний спочатку для ResultSetm, потім Statement, а в кінці для об'єкта Connection.

Важливо також знати, що будь-які винятки, які виникають при автоматичному виклику методів закриття, придушуються. Ці придушені винятки можна отримати методом getuppression (), визначеним у класі Throwable .

Джерело: https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html

Ігнорування винятків, які трапляються в блоці "нарешті", як правило, погана ідея, якщо тільки не відомо, якими будуть ці винятки та які умови вони представлятимуть. У звичайній try/finallyсхемі використання tryблок переводить речі в стан, зовнішній код якого не очікується, і finallyблок відновлює стан цих речей до того, що очікує зовнішній код. Поза зовнішнім кодом, який фіксує виняток, як правило, очікується, що, незважаючи на виняток, все було відновлено до аnormalдержава. Наприклад, припустимо, що якийсь код починає транзакцію, а потім намагається додати два записи; блок "нарешті" виконує операцію "відкат, якщо не здійснено". Абонент може бути готовий до винятку, який відбудеться під час виконання другої операції "додавання", і може очікувати, що якщо він виловить такий виняток, база даних буде в стані, в якому вона була до спроби будь-якої операції. Якщо ж під час відкату трапляється другий виняток, можуть трапитися погані випадки, якщо абонент зробить якісь припущення щодо стану бази даних. Відмова відката представляє собою велику кризу - ту, яку не слід сприймати за кодом, очікуючи простого виключення "Не вдалося додати запис".

Моя особиста схильність полягала б у тому, щоб остаточно вилучити винятки з методу, які трапляються, і загорнути їх у "CleanupFailedException", визнаючи, що такий збій є головною проблемою, і такий виняток не слід сприймати легко.

Одне рішення, якщо два Винятки - це два різні класи

try {
    ...
    }
catch(package1.Exception err)
   {
    ...
   }
catch(package2.Exception err)
   {
   ...
   }
finally
  {
  }

Але іноді не вдається уникнути цього другого пробного лову. наприклад для закриття потоку

InputStream in=null;
try
 {
 in= new FileInputStream("File.txt");
 (..)// do something that might throw an exception during the analysis of the file, e.g. a SQL error
 }
catch(SQLException err)
 {
 //handle exception
 }
finally
 {
 //at the end, we close the file
 if(in!=null) try { in.close();} catch(IOException err) { /* ignore */ }
 }

Чому ви хочете уникати додаткового блоку? Оскільки, нарешті, блок містить "звичайні" операції, які можуть кинути виняток І ви хочете, щоб блок, нарешті, запустився повністю, ВАМ ВИДАЛИТИ винятки.

Якщо ви не очікуєте, що блок нарешті викине виняток, і ви не знаєте, як в будь-якому разі поправити виняток (ви просто скиньте стек стека), нехай виняток міхурить стек виклику (видаліть спробу-улов нарешті блок).

Якщо ви хочете зменшити набір тексту, ви могли б реалізувати "глобальний" зовнішній блок "try-catch", який охопить усі винятки, кинуті в остаточні блоки:

try {
    try {
        ...
    } catch (Exception ex) {
        ...
    } finally {
        ...
    }

    try {
        ...
    } catch (Exception ex) {
        ...
    } finally {
        ...
    }

    try {
        ...
    } catch (Exception ex) {
        ...
    } finally {
        ...
    }
} catch (Exception ex) {
    ...
}

Після багато уваги я вважаю найкраще такий код:

MyResource resource = null;
try {
    resource = new MyResource();
    resource.doSomethingFancy();
    resource.close(); 
    resource = null;  
} finally {
    closeQuietly(resource)
}

void closeQuietly(MyResource a) {
    if (a!=null)
        try {
             a.close();
        } catch (Exception e) {
             //ignore
        }
}

Цей код гарантує наступне:

1. Після закінчення коду ресурс звільняється
2. Винятки, викинуті при закритті ресурсу, не обробляються без їх обробки.
3. Код не намагається закрити ресурс двічі, не буде створено зайвих винятків.

Якщо ви можете, вам слід протестувати, щоб уникнути помилки.

try{...}
catch(NullArgumentException nae){...}
finally
{
  //or if resource had some useful function that tells you its open use that
  if (resource != null) 
  {
      resource.Close();
      resource = null;//just to be explicit about it was closed
  }
}

Крім того, ви, мабуть, збираєте лише винятки, з яких ви можете відновити, якщо ви не можете відновити їх, тоді нехай він поширюється на найвищий рівень вашої програми. Якщо ви не можете перевірити на предмет помилки, вам доведеться оточити свій код блоком спробувати, як ви вже зробили (хоча я б рекомендував все-таки вводити конкретні, очікувані помилки).

Ви можете переробити це в інший метод ...

public void RealDoSuff()
{
   try
   { DoStuff(); }
   catch
   { // resource.close failed or something really weird is going on 
     // like an OutOfMemoryException 
   }
}

private void DoStuff() 
{
  try 
  {}
  catch
  {
  }
  finally 
  {
    if (resource != null) 
    {
      resource.close(); 
    }
  }
}

Я зазвичай роблю це:

MyResource r = null;
try { 
   // use resource
} finally {   
    if( r != null ) try { 
        r.close(); 
    } catch( ThatSpecificExceptionOnClose teoc ){}
}

Обґрунтування: Якщо я закінчую з ресурсом, і єдина проблема, яку я маю - це закрити його, я не можу з цим зробити багато. Не має сенсу вбивати цілу нитку, якщо я все-таки закінчую ресурс.

Це один із випадків, коли принаймні для мене можна ігнорувати цей перевірений виняток.

До сьогоднішнього дня у мене не виникло жодних проблем із використанням цієї ідіоми.

try {
    final Resource resource = acquire();
    try {
        use(resource);
    } finally {
        resource.release();
    }
} catch (ResourceException exx) {
    ... sensible code ...
}

Робота виконана. Немає нульових тестів. Одиничний вилов, включає винятки набуття та випуску. Звичайно, ви можете використовувати ідіому Execute Around і лише один раз написати її для кожного типу ресурсів.

Перехід Resourceвід найкращої відповіді доCloseable

Потокові програми реалізуються CloseableТаким чином, ви можете повторно використовувати метод для всіх потоків

protected void closeQuietly(Closeable resource) {
    if (resource == null) 
        return;
    try {
        resource.close();
    } catch (IOException e) {
        //log the exception
    }
}

Я зіткнувся з ситуацією, подібною до якої я не міг використати спробу з ресурсами, але я також хотів обробити виняток, що надходить із закриття, а не просто увійти в систему і проігнорувати його, як це зробити механізм closeQuietly. в моєму випадку я фактично не маю справу з вихідним потоком, тому відмова від закриття викликає більший інтерес, ніж простий потік.

IOException ioException = null;
try {
  outputStream.write("Something");
  outputStream.flush();
} catch (IOException e) {
  throw new ExportException("Unable to write to response stream", e);
}
finally {
  try {
    outputStream.close();
  } catch (IOException e) {
    ioException = e;
  }
}
if (ioException != null) {
  throw new ExportException("Unable to close outputstream", ioException);
}