Особенности обработки исключений

[andrew_lazarev]

А где же знаминитая потеря первопричины… если уж топик обзорный?

} catch (Exception e) {
      throw new Exception();
} 

или

} finally {
      throw new Exception();
} 

[dzmitryc]

На самом деле просто начал писать про заковырки с «finally», как-то не подумал :)

[EaE]

во-первых, да, про finally { throw new Exception(); } это тоже хороший пример.
а во-вторых, самого главного не написали, а именно — в какую степь должен послать интервьюируемый своего интервьюера, если тот пристанет к нему с таким примером.

[dzmitryc]

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

[EaE]

Не, я не имею в виду вставать и уходить; но знать подобные моменты — чести не больше, чем писать нерасшифровываемые однострочники на перле. Использовать же это в коммерческом коде смерти подобно. Сообщить об этом интервьюеру, если он человек вменяемый и дело свое знает, значит заработать больше очков, чем просто четко ответив на поставленный вопрос «так какой эксепшен все-таки вылетит».

[SCoon]

Я иногда даю на собеседовании подобные (но уровнем ниже) задачки, чтобы выявлять фриков от программирования. Если человек с радостью отвечает и начинает рассуждать о хитрых тонких механизмах — его ждет полный цикл тестов на программистскую вменяемость. Если в ответ смотрит на меня как на не совсем адекватного человека и демонстрирует недовольство неуместным вопросом — тест на вменяемость отменяется, человек явно здоров.

По крайней мере дважды это спасло мой проект — фриков радостно взяли соседи, потрясенные удивительной эрудицией. С соответствующимии последствиями.

[SCoon]

Посылать не нужно. Нужно сказать, что «данный код требует тщательного анализа и встретив его в реальном проекте я бы вначале выяснил, что он должен делать согласно требованиям, а затем переписал в форме, не вызывающей вопросов. Если Вы желаете, я могу проделать это сейчас. Что должен был делать этот код?»

Примерно так. :)

[EaE]

Это и называется «посылать», если собеседуешься в занудную контору. :)

[SCoon]

Посылать — это когда что-то неконструктивное в стиле «что за идиот у вас придумывает такие вопросы?»

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

[remal]

Буквально вчера или позавчера об этом писали.

[dzmitryc]

Немножко не о том. Если не ошибаюсь, была статья о нетривиальных возможностях, где был упомянут один момент с finally (фокус с System.exit).
Свою я написал независимо (несколько дней не заходя на хабр — проявлял силу воли :) ) и перед постингом, естественно читал хабр, чтобы не было дубля

[andrew_lazarev]

А еще Error от Exception не наследуется (о ужас?!). Будьте внимательны и осторожны.

[r3d]

По следам последнего примера.
Ты уверен, что у тебя происходит «нормальный» выход из программы? Ведь не зря ты поток демоном назвал.

[dzmitryc]

Вполне уверен. Все демон-потоки при завершении мгновенно и молча убиваются. Этот случай описан в «Thinking in java» в разделе Concurrency.

[dzmitryc]

"… при завершении всех не-демон-потоков"

[r3d]

Я правильно понимаю, что поток t завершится/умрет как только завершится выполнение метода main(...)?

[dzmitryc]

В приведённом примере — да.
Если же в приведённый код добавить запуск ещё одного потока, например t2, но для него не устанавливать флаг daemon, то оба потока продолжат работать после завершения main и до завершения t2.

[r3d]

Да, все вкурил javadoc.

[bobermaniac]

Я не понял, в JAVA return не является точкой выхода?

[dzmitryc]

Является. Но не всегда мгновенной и окончательной :)
Хотя, код с несколькими вложенными try-catch-finally с отменами и переопределениями return-ов у меня до сих пор с магией ассоциируется

[bobermaniac]

То есть не является, а является чем-то вроде паскалевского := Точка выхода — это значит, что она мгновенная и окончательная.

[SCoon]

Даже нормальном завершении программы, в потоках типа «daemon» блок finally не отрабатывает.

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

[dzmitryc]

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

[SCoon]

Daemon-потоки предпочтительны именно в тех случаях, когда известно, что процесс допустимо прервать в любой момент и не требуется никакая очистка. Вариант с ExecutionService решает задачу в более общем виде, но требует, чтобы в какой-то точке мы приняли решение, что пора делать shutdown. Вариант с daemon-потоком позволяет получить это автоматически.

P.S. Я за последние 10 лет использовал daemon-потоки в реальном коде как максимум 2 или 3 раза. :)

[maxcom]

return в finally это дурной тон

[dzmitryc]

Но тем не менее компилятор его пропускает. Поэтому всегда найдётся тот, кто напишет такой код. И кто-то другой, кому этот код придётся понять и модифицировать.

[Helpa]

IntelliJ IDEA отлавливает return в finally и предупреждает — так что пишущий такое должен заметить.