- 1
- 2
- 3
- 4
- 5
- 6
try{
name.toLowerCase();
}catch (NullPointerException e) {
report().error("java.lang.NullPointerException", e);
name = "";
}-
Java / Говнокод #12286
+83
Перспективная проверка на null
Запостил:
nafania217518,
13 Декабря 2012
Follow us!
%)
Ну некрасиво смотрится ведь!
ни к чему не приводит, ведь значение name останется таким же, как и до вызова toLowerCase.
... подумал программист и, не долго думая, удалил строку 2.
А от записывания (и тем более от бросания) NullPointerException тут вообще надо бы отказаться. Мы ведь уже предусмотрели, что делать в случае (name == null).
%)
В этом случае, за исключением репорта, тут полностью сохраняется семантика фрагмента.
Кажется я понял мотив того, кто писал данный код.
У автора кода возникла проблема - код крашился в непонятном месте с NPE, но логирования еще не было. Клиенты уже злые, и доводить дело до крешлога в следующий раз нельзя...
Поэтому автор принял такое решение - перед каждым подозрительным местом он вставляет приведенную ОП'ом заглушку, которая сохранит бектрейс в лог (именно для этого вброшено исключение), а значение заменяет на пустую строку, чтобы программа могла продолжить работу.
Затем, через некоторое время, он прочтет лог, поймет где же возникает NPE, и выпилит эти заглушки.
[/SherlockHolmes]
Настоящие жависты toString() безопасный от NPE, делают так: ""+obj.
Тут как раз в соседнем треде обсуждали, что в Objective C на null'ах можно вызывать что угодно, и оно промолчит и не крашнется.
Зачем NPE? Идиотия.
Кстати мне нравится в C# extension methods, то что они так и сделаны.
Ну как зачем. При вызове через null жаба тупо не знает, метод какого класса ей вызывать.Здесь я вижу только три варианта:
1) Ничего не вызывать, и вернуть 0.0, 0, null или false, в зависимости от типа результата.
2) Вызывать метод согласно типу переменной (в данном случае Object), подсунув ему null в this.
3) Сделать нуллы типизированными (null перестанет быть пустой ссылкой, а будет ссылкой на null-объект соотвествующего класса) - запретить использовать просто null, а писать что-то в духе Foo.null или Bar.null.
И все они мне нравятся еще меньше чем экцепшн, или необходимость ручной проверки на null...
>И все они мне нравятся еще меньше чем экцепшн, или необходимость ручной проверки на null...
Тоже щитаю, что NPE - меньшее из зол.
Могли хотя бы обращения к полям null ового объекта выдавать как null.
Хотя с повальными getter/setter и отсутсвием сахара в виде свойств это никого бы не спасло.
Короче NPE-говно в крестах, жабе и решетке у самого основания.
Необходимое зло ;(
> Ради полиморфизма - убогой пародии на мультиметоды.
Да кстати, полноценный мультиметод не смог бы быть членом класса (и даже статиком), поэтому они бы разнесли уютненький мир жабы и шарпика к хуям.
Лолчто? Существуют не симетричные мультиметоды. Они они даже по сильнее симетричных:
2) Ну висит он себе в статике. Как я его вызывать то буду? Допустим есть такой код: Если эта конструкция не работает - то как мне вызвать этот "мультиметод"? Через Foo.multi() ? Ну и нахуй он тогда сдался? А если работает - то метод уже нихуя не член класса, т.к. вывалился из положенной ему области видимости...
Лолшто?
AHAH А у тебя стасик не подсвечивает
ps:Чё это меня разлогинило?
PPPS: Знаю что вас много. Но меня как истинного борща за свободу это не волнует.
Они там есть.
А еще чудесное слово dynamic. Определяет какой метод вызввать в рантайме.
Проблема в том что если оно не может разрулить какой метод вызвать - есть альтернативы, или вообще без вариантов, то оно в том же рантайме и падает.
Это не мультиметоды, это утиная типизация.
Ну с этой фичей можно забыть о полиморфизме.
4)Метод вернет Maybe.Nothing вместо результата.
5)Объект Null примет сообщение toString и решит как его обработать. Может исключение, а может ещё что-то. Хотя потомок все объектов Object.Null мне больше нравится. Так можно больше вариантов для обработки и изменения поведения сделать.
Вызов же обычного метода будет разруливаться в рантайме - ведь вместо объекта могут подсунуть его потомка. И вот там null уже довольно фатален, т.к. рантайм не знает, что ему вызвать.
Только статика, только хардкор!
А полиморфизм мы заменим ссылками на функцию, делегатами или фп!
И с тарасоформатированием, обязательно!!!
Хотя "тарасоформатирование" и устоявшийся тут термин, но эксклюзивных прав Тарасу форматировать так код никто не давал, поскольку я, например задолго до всех обсуждений на гк юзаю подобный подход.
Попробуем применить эту идею к яве. Разобъем типы на 2 категории - допускающие нулл (обозначим как nullable в шарпике через Object?) и недопускающие (обозначим Object). Object можно невозбранно кастовать в Object?, но не наоборот. При вызове метода на Object? метод автоматически лифтится, и если он возвращал T, то полученный метод будет возвращать T?.
Пример:Вот такая вот концепция пришла в мою сонную голову. При такой схеме NPE невозможно. Любая возможность его появления жестко пресекается компилятором.
Псевдокод:
Таким вот нехитрым образом через икстеншен методы добавлять можно недомонады. toString вызовется только если 'a' не null, а затем если 'a' не нуоль и результат toString не null вызывается print.
Проблема "умного" подхода ровно в одном: кода получается больше, читается он хуже и работает чуть медленей, чем "тупые" ifы.
ЗЫ. А. Теперь вижу хорошую, олдскульную картинку. Плюс.
Где-то у меня была сцылка на редкость упоротого поциента, который монадил в шарпе.
виртуального
лолчто?
this.method(params) по сути сахар над
А в яве вообще нет.
P.S. Ну собственно ява сама по себе совсем простой язык. На порядки проще решеток и крестов, где-то в районе питона. Все сложности начинаются в ее стандартной либе...
Я бы упомянул про final - раз. Про static - два. Ну ладно - нет, так нет.
>Ну собственно ява сама по себе совсем простой язык.
Да, одна из немногих положительных её сторон, что они вдохновлялись минимализмом Вирта.
>Все сложности начинаются в ее стандартной либе...
Не будем о плохом...
final на переменных тоже вроде как ограничение для компилятора, а внутри HotSpota - это флаг который влияет на то когда можно публиковать объект.
static - ну статики да, не виртуальные, само собой, но у них и this нет, поэтому хрен с ними.
Ибо метод не из интерфейса, а сам класс String - финальный.
Более того даже если у тебя самый обычный нефинальный класс без родителей и наследников, то вм может догадаться и заинлайнить его методы.
В HotSpote они даже оптимизируют полиморфизм для джвух наследников, а такие простые случаи и подавно.
То есть теоретически bormand - прав, по дефолту всё виртуальное, но внутри jvm оно может быть как просто вызовом, так и вообще инлайнится в код.
Возможно поэтому Блох в книжке рекомендует писать побольше finalов и запрещать наследование, там где не предполагается расширять в дальнейшем.
Как-то так?
http://www.javaspecialists.eu/archive/Issue158.html
We run this six times, one for each test case. Here are the test cases:
When you run it with Java 6 -server, A1 and A2 come back with an average of 0 (0). The standard deviation is in brackets. In the case of a simple pointer to B or where there is a single subclass of B, the method call is inlined.
A3 is the bi-morphic case, where we have two subclasses of B. In this case, the results come back as 495 (9).
according to Cliff Click, deals with bi-morphism as a special case of poly-morphism: "Where the server compiler can prove only two classes reach a call site, it will insert a type-check and then statically call both targets (which may then further inline, etc)."
"HotSpot uses an inline-cache for calls where the compiler cannot prove only a single target can be called. An inline-cache turns a virtual (or interface) call into a static call plus a few cycles of work. It's is a 1-entry cache inlined in the code; the Key is the expected class of the 'this' pointer, the Value is the static target method matching the Key, directly encoded as a call instruction. As soon as you need 2+ targets for the same call site, you revert to the much more expensive dynamic lookup (load/load/load/jump-register). Both compilers use the same runtime infrastructure, but the server compiler is more aggressive about proving a single target."
>TCockB
Лол, только сейчас обратил внимание на нейминг.
Тип того. Он не лезет в таблицу, а прописывает адреса для calla явно.
Как видим, ускорение, от меньшего кол-ва обращений к памяти, около 5-6 раз.
Ява раньше была очень тормозной, а из-за реализации таких вот вещей она стала просто тормозной.
И всё-таки быстрее, чем тот же js, хацкиль или питон. А если на каждый чих лезть в таблицу виртуальных методов это катастрофически понизит скорость.
Вот насчёт хацкила, кстати, неуверен.
Он хоть худо-бедно, но изначально компилился в натив. А в жабе 1.1 только интерпретация байт-кода, только хардкор. Да и потребление памяти у него всегда было значительно меньше (при рациональном коде, разумеется)
Всё что выигрывается на assParallel, то и тратится на иммутабельность.
Но зато простор для оптимизации и роста - огромный.
А еще scala иногда быстрее чем "оптимальный" код на жабе.
Плюс scala быстрее и короче хацкиля.
Знаю я как бенчи делают. Очень трудно сделать объективно.
Идеальный бенч должен делать человек, которому похуй на обе системы. Но т.к. ему похуй, он его делать не будет. Поэтому честных бенчей нет :(
А то скала получается быстрее чем жаба в которую она транслируется.
Это как сишка получилась бы быстрей ассемблера.
В общем то если взять матёрого сишника, и нуба-ассемблерщика, то так оно и будет. Что-то мне подсказывает, что и со скалой был точно такой же бенч.
Проблема в том, что задание для бенчмарка должен составлять нейтральный человек. Иначе он придумает такую задачу, которая легче реализуется на том языке, который ему больше нравится...
Ещё вариант - попросить какого-нибудь математика задачу составить, который кроме матпакета ничего и не видел.
Нужны задачи приближенные к практике. С этим никто спорить не будет?
а не что-то а-ля projecteuler.
Но это область нативной сишки и асмовставками.
Хаскель не может в асмовставки
Ну на том сайте вроде так и делают.
А хацкиль делает жабу в среднем зачете, только потому что джва последних теста: Bad Output и No program.
Так вот жаба сливает скале и хацки в бенче с интересным неймом pinumbers.
Ну во-первых в глаза бросилось читерство:
http://shootout.alioth.debian.org/u32/program.php?test=pidigits&lang=java&id=2
И шо это за гумно? Наверное вывод в буферизованный поток еще не проходили.
Скала кстати тоже так написана.
Наверное сравнивают скорость буферизации при выводе и либы, а не языки.
а зачем вот эта строчка ?
Я бы ее тоже грохнул, особого смысла в ней не вижу
Более того, я в ней вижу зло, потому что, во-первых, занимает ресурсы на генерацию исключения, а во-вторых, засоряет лог, ведь полезной информации не даёт.