Comments 42
«квалифицированное имя, то есть полное имя»
Просто «полное имя». Ни в русском языке, ни в программистском жаргоне такого понятия нет. Появилось в результате подстрочного перевода qualified name.
Просто «полное имя». Ни в русском языке, ни в программистском жаргоне такого понятия нет. Появилось в результате подстрочного перевода qualified name.
А вот чем руководствовались разработчики, выдумывая второе слово, остаётся только догадываться:)
Magic Number
А может по Фрейду? :)
Гослинг говорил, что спонтанно придумал babe и ему просто понравилось. Но с тем же успехом и более подходяще по смыслу можно было придумать cafe feed. Так что, по-моему, вопрос открыт.
Вы уж простите, но пункты 6 и 7 не могу назвать малоизвестными даже я со своими знаниями недоджуниора. Ну и говорить «А» и не говорить «Б» не хорошо:
Подсписки следует использовать с осторожностью из-за особенностей, вытекающих из их сути (для подробностей смотрите документацию).
Да и короткое гугление по 10 пункту выдало куда больше интересного, чем сухой намек в топике. http://stackoverflow.com/questions/48088/returning-from-a-finally-block-in-java
С 9ым еще проще оказалось. Все написано в вики.
С 8ым пунктом в спеку поленился лазить, а в документации написано, что проблемы могут быть при обращении к подсписку в случае изменения структуры и размера исходного листа. Полагаю, что это произойдет только в случае, когда будут затронуты элементы, входящие в диапазон подсписка. Других предупреждений нет.
Повторюсь, заголовок несколько неудачный… для Java-гуру, коим я не являюсь, а для остальных, я считаю, ничего себе так.
И, вот к примеру, я знаю что в C++ что a[b], что b[a] эквиваленты для массивов, поскольку арифметика указателей. Однако я довольно плохо разбираюсь в ООП-тонкостях этого языка.
И, вот к примеру, я знаю что в C++ что a[b], что b[a] эквиваленты для массивов, поскольку арифметика указателей. Однако я довольно плохо разбираюсь в ООП-тонкостях этого языка.
девятый пункт особенно порадовал
По поводу 6-ого пункта и русских имен: все зависит от JDK и операционной системы. Был реальный случай, когда в имени переменной был русский символ. Код собирался и компилировался под ubuntu, windows, а вот на solaris выдавало ошибку. В своих проектах придерживаемся латиницы из-за распределенной комманды.
цикл статей немного странный — представленные примеры выглядят просто бессистемно выхваченными приемами программирования из тех, «о которых я до этого не знал». Большинство тривиальны, а часть не разобраны, как следовало-бы.
Возмём последний —
«throw null» выглядит так, как будто «null» эквивалентно «NullPointerException». Нв самом деле, «throw» тупо падает (сорри — бросает исключение) при попытке использовать нулевой объект. Потом управление переходит в «finally», как оно и должно, и «finally» переопределяет поведение.
Проблема с данным конкретным случаем в том, что он подан как «магия! будьте бдительны!».
Правильно было-бы объяснить отдельно два базовых правила языка:
1. если вызывается «throw» для создания исключительной ситуации, и в процессе её создания происходит другая исключительная ситуация, то первая отбрасывается. Простой пример может быть если конструктор исключительной ситуации слишком сложный и пытается, к примеру, писать в файл, или добраться до данных по нулевому указателю — будет сгенерирована другая исключительная ситуация.
Это именно то, что здесь и происходит.
2. В блоке «finally» или «catch» можно «заглушить исключительную ситуация». Пример с «return;» менее интересен, чем, например, более жизненный пример с вызовом «close» потока в «finally», который потенциально может сбоить. Проблема в том, что при сбое обработчика «finally» теряется оригинальная исключительная ситуация, и становится невозможно диагностировать проблему по логам.
Или возьмем пример с переменным количеством аргументов — эта супер-пупер фича, к сожалению, хромает на обе ноги с параметеризированными классами.
Или пример с Arrays — если про него рассказывать, то стоит упомянуть про ArrayUtils, CollectionUtils, etc.
— В-обсчем Ж-), автору пожелание — пришите больше, только старайтесь глубже прорабатывать материал. Этот цикл слишком поверхностный для своего названия.
Возмём последний —
try {
throw null;
} finally {
return;
}
«throw null» выглядит так, как будто «null» эквивалентно «NullPointerException». Нв самом деле, «throw» тупо падает (сорри — бросает исключение) при попытке использовать нулевой объект. Потом управление переходит в «finally», как оно и должно, и «finally» переопределяет поведение.
Проблема с данным конкретным случаем в том, что он подан как «магия! будьте бдительны!».
Правильно было-бы объяснить отдельно два базовых правила языка:
1. если вызывается «throw» для создания исключительной ситуации, и в процессе её создания происходит другая исключительная ситуация, то первая отбрасывается. Простой пример может быть если конструктор исключительной ситуации слишком сложный и пытается, к примеру, писать в файл, или добраться до данных по нулевому указателю — будет сгенерирована другая исключительная ситуация.
Это именно то, что здесь и происходит.
2. В блоке «finally» или «catch» можно «заглушить исключительную ситуация». Пример с «return;» менее интересен, чем, например, более жизненный пример с вызовом «close» потока в «finally», который потенциально может сбоить. Проблема в том, что при сбое обработчика «finally» теряется оригинальная исключительная ситуация, и становится невозможно диагностировать проблему по логам.
Или возьмем пример с переменным количеством аргументов — эта супер-пупер фича, к сожалению, хромает на обе ноги с параметеризированными классами.
Или пример с Arrays — если про него рассказывать, то стоит упомянуть про ArrayUtils, CollectionUtils, etc.
— В-обсчем Ж-), автору пожелание — пришите больше, только старайтесь глубже прорабатывать материал. Этот цикл слишком поверхностный для своего названия.
пока я все так длинно писал, вверху уже накидали ссылок и пояснений :-)
Finally, насколько я понял, может «вылететь» только если умер поток с этим блоком или свалилась jvm. Неожиданности вызваны именно использованием return, который находясь в finally замещает остальные точки возврата из метода (exception и return в try и catch). Везде как решение предлагают вариант только не использовать return в finally.
Очень хорошо, что вообще написал и инициировал обсуждение темы.
Статья вместе с содержательными комментариями очень даже интересна.
Да и вообще есть правило:
Если не можешь решить для себя какой-то вопрос, напиши о нём в вызывающей форме в интернетах, будет много мнений для подумать.
Статья вместе с содержательными комментариями очень даже интересна.
Да и вообще есть правило:
Если не можешь решить для себя какой-то вопрос, напиши о нём в вызывающей форме в интернетах, будет много мнений для подумать.
Пункт 10 был для «домашнего задания». Но вы его решили почти за всех.
Я специально написал про throw null, это была «дополнительная магия». Так тоже можно бросать исключения. Это скорее из разряда багов.
Я специально написал про throw null, это была «дополнительная магия». Так тоже можно бросать исключения. Это скорее из разряда багов.
try {
throw new ArithmeticException();
} finally {
throw new NullPointerException();
}Ну по сути в данном случае все тоже самое. Только все точки возврата из метода в блоке try заменяет не return, а исключение из finally.
Промазал. Цель здесь
Я был уверен, что хабровчане на пункт №10 дадут развёрнутый ответ. Ещё можно в catch-блоке бросить с тем же эффектом.
Прошлый топик был интереснее и информативнее… Опять сиквел провалился
Вопрос к гуру: что произойдет, если один и тот же объект хранится в разных списках? Вернее можно ли добавить его в 2 разных списка? На это ругнется компилятор?
Вопрос к гуру: что произойдет, если один и тот же объект хранится в разных списках? Вернее можно ли добавить его в 2 разных списка? На это ругнется компилятор?
> 10. Исключительные ситуации.
> Здесь выбрасывается NullPointerException и… теряется, исчезает без следа! Будьте бдительны.
Правильнее сказать не «Будьте бдительны» а "Ни в коем случае не используйте return или throw в finally блоке — это считается плохой практикой".
> Здесь выбрасывается NullPointerException и… теряется, исчезает без следа! Будьте бдительны.
Правильнее сказать не «Будьте бдительны» а "Ни в коем случае не используйте return или throw в finally блоке — это считается плохой практикой".
UFO just landed and posted this here
То что new LinkedList(Arrays.asList(4, 8, 15, 16, 23, 42)) по пути создаст еще один массив никого видимо не волнует :)
Автору зачет. В яве есть много про что писать. Пишите еще. Особенно много можно написать про оптимизации компилятора, которые непредсказуемо меняют поведения кода :)
Ну так как же помимо цифр. Integer x1; вполне себе валидное имя переменной.
Правильно, помимо буквы «x», в вашем идентификаторе используется цифра «1». В чём, собственно, проблема?
если бы вы только знали какая автор сука
Sign up to leave a comment.
Малоизвестные особенности Java. Вторая часть