Возникли следующие соображения.
Показ шампура try , а справа от него шампуров catch интуитивен и нагляден.
Шампуры catch при этом скорее ветки, функционально, чем варианты выбора, или последовательность вопросов.
Но в целом оператор try-catch, часто защищающий единственный оператор и полностью умещающийся в одну икону, как у Степана - локальный маленький оператор, а не целый набор веток силуэта, это пушкой по воробьям.
И для полноты картины хотелось бы иметь вложенный try, что в силуэте выглядит как мешанина веток, текстовые ссылки на ветки try отнюдь не интуитивны для прояснения простой вложенности элементарных блоков кода.
Интересно с finally - нужно ли его размещать в главном шампуре после try и catch.
Да, в простом случае finally выполняется после try или catch, как и показывают линии в варианте Эдуарда.
Но для такого простого случая код try { a } catch () { b } finally { c } полностью эквивалентен try { a } catch () { b } c , без всякого finally.
finally работает по особому в следующих случаях:
- если в try { } возникает Exception , не пойманное блоками catch () {} .
Прежде чем выйти из функции с Exception, выполнится блок finally (сначала текущего try, потом родительских).
Линии, соединяющие у Эдуарда шампур try и finally, а также finally с последующими операторами в шампуре показаны, но не работают.
А тот факт, что сразу после блока finally произойдет выход из алгоритма не показан, но важен.
В следующих случаях, аналогично:
- если в catch () { } возникает Exception
- если в try { } или catch () есть оператор return
- если в try { } или catch () есть оператор break или continue
Затем, есть finally вложенных try - в случае непойманной Exception блоки finally вложенных try выполнятся по одному в порядке, не обязательно совпадающем с изображенным на шампуре.
Во всех этих случаях, изображение finally как самой правой ветки как бы локального силуэта вполне работает - как говорят по английски, last but not least, и в моем последнем варианте вложенные finally выполнятся слева направо.
Тем более что функционально finally чаще всего используется только для одного: закрытии обьектa, связанного с ресурсами - ровно один оператор ...close(), что называется уборка мусора.
Известно, что в Java не приходится явно освобождать память, занятую локальными обьектами, это делается автоматически.
Таким же образом, размещение оператора освобождения файла на главном шампуре - довольно опционально, т.е. его отсутствие не меняет смысла главного алгоритма, это дело вторичное, легко постигаемое передвижением глаз направо
Вход
FAQ
Поиск
