написал(а) ...

public void enumerateBar() throws SQLException {
Statement statement = null;
ResultSet resultSet = null;
Connection connection = getConnection();
try {
statement = connection.createStatement();
resultSet = statement.executeQuery("SELECT * FROM Bar");
// Use resultSet
}
finally {
try {
if (resultSet != null)
resultSet.close();
}
finally {
try {
if (statement != null)
statement.close();
}
finally {
connection.close();
}
}
}
}

К тому же конструкция try-catch гораздо элегантнее, чем анализ возвращенного значения из метода.

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

"Этого никогда не случится..."

И далее: "Через 30 лет эта программа использоваться не будет, так что для обозначения года хватит и двух разрядов"". "Нужна ли интернационализация, если это приложение не будет использоваться за рубежом?" "Счетчик не может принимать отрицательное значение". "Этот оператор printf не дает сбоев".
Не стоит заниматься подобного рода самообманом, особенно при написании программ.

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

«Паранойя — профессиональное заболевание специалистов по безопасности. Но любители могут в этой области зайти гораздо дальше» (c) В. Гайкович.

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

Но конечно результат fopen обязательно надо проверять!

Это значит, что данное исключение вызывающий метод должен обработать в catch либо так же объявить.

К тому же программа легче читается - обработка ошибок и анализ возвращенного значения разделены.

Vadim Ushakov написал(а) ...
Когда я вижу такой код, то готов согласиться с последователями Вирта, что исключения суть зло.

Vadim Ushakov написал(а) ...
Абракадабра...

Vadim Ushakov написал(а) ...
Можно привести массу примеров, когда это реально помогает. Например переполнение буфера затерло значение переменной FILE* file.

try {
transaction.begin();
//bla bla bla
//bla bla bla
transaction.commit();
} catch (Exception ex) {
transaction.rollback();
}

transaction.begin();
//bla bla bla
//bla bla bla
transaction.commit();

Понятие "исключение" противоположно понятию "транзакция".
Если исключение вылетит в "неучтённом" месте, данные могут остаться в противоречивом состоянии. Ещё хуже если не просто данные в памяти а внешние ресурсы. И механизм исключений не даёт никаких средств откатить незавершённую транзакцию.

catch-finally - наиболее подходящие места для освобождения ресурсов (закрытия соединений, откат транзакций)

И опять же повторюсь: сборщик мусора тут совсем ни при чем. Он всеголишь освобождает память от неиспользуемых, недостижимых объектов, т.е. тех, на которые нету ссылок.

fedukoff написал(а) ...
Да ну!? Докажи!

fedukoff написал(а) ...
Что значит "Даже если удалось"?

Vadim Ushakov написал(а) ...
В Си++ иницирование исключения запускает раскрутку стека и приводит к вызову по очереди всех деструкторов объектов, удаляемых из стека, пока не найдется точка, в которой исключение может быть обработано. Именно в раскрутке стека заключается вся "соль", а не в try-catch.

Исключение - это исключительная ситуация. Или иначе "непредусмотренная ситуация".

Введение в язык механизмов обработки исключений - это попытка "предусмотреть непредусмотренные ситуации".

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

А теперь вспомним что при выходе автоматического объекта из области видимости неявно вызывается деструктор. То есть выход из области видимости - это тоже "раскрутка стека", но без try-catch. То что нужно. Тогда обработка исключений в языке - не нужна. Правильно?

Что мы видим?
Мы видим семантическую связность между transaction.* и //bla bla bla

Это означает что они взаимодействуют через глобальный контекст.

И поэтому каждый раз когда мы изменяем //bla bla bla мы должны также проверить transaction.* чтобы убедиться что он ещё работает. И если забыть/ошибиться, код станет некорректным.

И механизм исключений не даёт никаких средств откатить незавершённую транзакцию.