jdo123очему так? и почему не бросается exception?
Потому что у тебя return стоит, и программа завершается раньше, чем выводится эксепшн. Убери ретурн - и увидишь потерянное.

Хотя почему оно так делает вместо выкидывания исключения из метода - тайна велика есть :)

В общем, это идеологическая фишка Сана, но с какой целью была внедрена в таком виде - спрашивать надо у Гослинга. Я лично такое поведение прозрачным не считаю.
З.Ы. Из туториала:
If the finally block does include a transfer of control, then that takes precedence over any transfer of control executed in the try or in an executed catch clause. So for all of the cases listed above, the finally clause would execute, then its transfer of control would take place. Here's one example:

The result of executing this code is that 2 is returned.

Note that this is rather confusing! The moral is that you probably do not want to include transfer-of-control statements in both the try statements and the finally clause, or in both a catch clause and the finally clause.

Blazkowicz ЗашедшийХотя почему оно так делает вместо выкидывания исключения из метода - тайна велика есть :)

Какая тут тайна? Есть простое как валенок правило: блок finally выплняется всегда, кроме клинических случаев вроде остановки JVM.
Что он выполняется всегда - это понятно. Но нелогично то, что при наличии необработанного исключения блок finally позволяет передать управление и забить на это исключение - что есть преррогатива только блока catch. В итоге Сану приходится делать дополнительное примечание "никогда-никогда не используйте передачу контроля из finally, чтобы избежать потери исключения". И, спрашивается, зачем было делать некую фичу, которую не рекомендуют использовать - вместо того, что просто сделать поведение более логичным?

Blazkowicz ЗашедшийЧто он выполняется всегда - это понятно. Но нелогично то, что при наличии необработанного исключения блок finally позволяет передать управление и забить на это исключение - что есть преррогатива только блока catch. В итоге Сану приходится делать дополнительное примечание "никогда-никогда не используйте передачу контроля из finally, чтобы избежать потери исключения". И, спрашивается, зачем было делать некую фичу, которую не рекомендуют использовать - вместо того, что просто сделать поведение более логичным?

Предлашаемое Вами поведение не является более простым или логичным решением. Во-первых по бритве Оккама текущее поведение при прочих равных проще, соответсвенно и реализовано. Если же сделать наоборот. То сразу возникает вопрос а как быть с throw в блоке finally. Ведь тогда исключение из catch выполнится. А из finally по какой-то таинственной причине - нет. Соответсвенно и весь код в блоке finally будет работать как-то не логично и не понятно.
Что-то не понял Вашего предложения. Я считаю, что было бы логичным при наличии неперехваченного исключения в finally не передавать управление по return, а выкидывать его. Либо на уровне компилятора запретить использование передачи управления в finally.

BlazkowiczТо есть запретить там как return так и throw вообще? Это тоже по-твоему логично?
Вполне логично. Return может скрыть необработанные исключения, что не есть хорошо. К тому же я себе слабо представляю, с какой целью надо использовать return в finally. То есть - когда такое решение будет лучше, чем возврат из try или catch. Можете попробовать привести пример такого решения. Далее, throw тоже очень даже неплохо запретить, потому что блок finally предназначен только для гарантированного освобождения ресурсов, а никак не для обработки исключений. Надо заменить исключение - используйте catch, кинуть исключение - try.

wessen Зашедший
Далее, throw тоже очень даже неплохо запретить.


А если я захочу в блоке fynally сделать throw и там же его поймать? Это тоже не логично?
Use nested try...catch.

BlazkowiczНачало понятно, но завершить мысль у Вас не получается. Вопрос. С какой-такой стати мне должно быть запрещено пробрасывать исключения в блоке finally??? Поймал одно исключение, пытаюсь закрыть ресурс, происходит ошибка закрытия ресурса, и теперь что? Я обязан обработку этого исключения всегда в finally делать? А как мне сообщить о нем другим уровням приложения?
Тут с throw как ни крути, все равно нормального поведения не сделать. Собственно, я имел в виду запретить прямое выкидывание исключений, только если их возвращают вызываемые методы.
З.Ы. Вот wessen привел чУдный пример того, как поведение метода становится слабопредсказуемым...

Blazkowicz ЗашедшийЗ.Ы. Вот wessen привел чУдный пример того, как поведение метода становится слабопредсказуемым...

Да где же оно не предсказуемое? Ночью меня разбудить и такой код показать я вам скажу что будет. А все потому что это поведение описывается одним простым правилом которое так легко запомнить.
Выполнение секции finally? Обяснить такое поведение можно, но выглядит оно несколько неочевидно. Сугубое имхо.

"Двукратное выполнение..."

Blazkowicz ЗашедшийВыполнение секции finally? Обяснить такое поведение можно, но выглядит оно несколько неочевидно. Сугубое имхо.

Вы таки не знакомы с принципом бритвы Оккама? Это решение при прочих равных самое простое.
Почему при прочих равных? Потому что все альтернативы так же будут иметь подобные странности, но при этом их поведение будет описать сложнее. А значит и понять тоже.

Хотя в одном я могу согласить. return в finally можно было бы и запретить. Только сейчас подобные изменения в Java невозможны из-за обратной совместимости, которой в Sun так гордятся. Максимум warning новый моэно добавить.
Сей принцип преподают на первом году любого вуза, в составе курса философии. Надо очень постараться, чтобы не знать. И - да, я не считаю подобное поведение самым очевидным. Собственно, с ненужности в finally использования return разговор и начался. Вот насчет запрета throw я погорячился, не спорю. И кроме того, двухкратное выполнение секции тоже не слишко однозначно, логически было бы яснее, если при возникновении в завершающей секции метода finally это исключение просто будет пробрасываться наружу.