Едешь себе такой, а у тебя оом вылетел

В процессе работы безопасного ПО, выделение новой памяти не происходит.

Немного статистики о Spring Boot: https://twitter.com/yegor256/status/983383515642433538

Сравнивать именно спрингбут в отрыве от его зависимостей с чем-либо - странная затея.

Ну, как минимум спринговых зависимостей

Ну, как минимум спринговых зависимостей

Там тоже нужно было NULL посчитать?)

Там тоже нужно было NULL посчитать?)

Ну да (и статистику lines per null пересчитать).

Как бы не оказалось, что почти все эти null - это проверки при работе с Reflection API или чем-нибудь ещё внешним. Тогда это количество совершенно ничего не говорит о качестве кода, а только о том, в каком окружении он работает.

NULL считается вредной практикой в ООП коде (и не только в нем). Вот мой анализ этого, и это не только мое мнение: http://www.yegor256.com/2014/05/13/why-null-is-bad.html

Хорошая статья, спасибо

Как бы не оказалось, что почти все эти null - это проверки при работе с Reflection API или чем-нибудь ещё внешним. Тогда это количество совершенно ничего не говорит о качестве кода, а только о том, в каком окружении он работает.

Да, все так, если бы разница не была такой огромной.

The security manager is an object of type SecurityManager; to obtain a reference to this object, invoke System.getSecurityManager. SecurityManager appsm = System.getSecurityManager(); If there is no security manager, this method returns null.

Нуллы такие нуллы

Раньше не было оптионов в джавке

Что поделать

Синглтоново хотя бы

Что поделать

Поделать: писать ООП код, а не процедурный. Optional здесь не при чем.

NULL — это ошибка дизайна.

Допустим, Map#get() возвращает NULL, если ничего не найдено

Допустим, Map#get() возвращает NULL, если ничего не найдено

А должна была?

Странно что в статье не упоминается Optional<>, который как раз и добавлен в язык для решения проблем с возращаемым null.

Это кривой JDK дизайн. Так не должно быть. Вместо этого, должно быть как в C++: должен возвращаться итератор.

Допустим, Map#get() возвращает NULL, если ничего не найдено

А нужно не null возвращать?

А нужно не null возвращать?

value, ok := map.Get() ?

Либо должен быть Exception. Но не NULL ни в коем случае.

Exception?

value, ok := map.Get() ?

Попахивает гошечкой...

srsly

Либо должен быть Exception. Но не NULL ни в коем случае.

Понял.

Либо должен быть Exception. Но не NULL ни в коем случае.

желательно checked ?

Exception для логики?

серьезно?

желательно checked ?

конечно

srsly

В статье собственный ексепшн. Написанный. Поэтому почему бы и нет

анчекед эксепшн тоже не ооп

Или File.listFiles() возвращает NULL, если файлов нет. Это дефективный дизайн.

Мой код в любом случае говнокод ?

Это кривой JDK дизайн. Так не должно быть. Вместо этого, должно быть как в C++: должен возвращаться итератор.

итератор... Optional?)

конечно

в итоге все закончится ломбочной аннотацией SneakyThrows и все станет еще хуже

Или File.listFiles() возвращает NULL, если файлов нет. Это дефективный дизайн.

тогда что возвращать . допустим функция возвращает Integer объект?

Exception выбрасывать. и чем чаще, тем лучше

Optional оборачивать?

Вообще, думаю это очевидно, что чем чаще ваш код бросает Exception, тем выше будет конечное качество продукта для юзера.

Когда идёшь по лестнице и думаешь что осталась ещё 1, а её нет, и ловишь ексепшн хлебалушком . Дефекты дизайн лестницы, или кто то не проверяет куда шагает?

Вообще, думаю это очевидно, что чем чаще ваш код бросает Exception, тем выше будет конечное качество продукта для юзера.

так толсто, что даже тонко

Вообще, думаю это очевидно, что чем чаще ваш код бросает Exception, тем выше будет конечное качество продукта для юзера.

Не покроется ли тогда код бесконечными траями?

Не покроется ли тогда код бесконечными траями?

В идеале TRY должен быть один, на самом верху.

Почитайте про Fail Fast, вот эту статью: https://www.martinfowler.com/ieeeSoftware/failFast.pdf

В optional обернуть и все?,

О, знаю такое! try {...} catch (Exception ex) {}

Я так в школе писал олимпиадные задачи

О, знаю такое! try {...} catch (Exception ex) {}

Да, именно так, в одном месте, на самом верху.

а еще TRY CATCH на русском это трюкач:)

В optional обернуть и все?,

Меня тоже интересует вопрос Optional (и почему он обойдет вниманием)

О, знаю такое! try {...} catch (Exception ex) {}

только не Exception, а Throwable ?

только не Exception, а Throwable ?

Верно

Собственно, если вы его не пишете, то его за вас пишет JDK.

и без трюкача можно в 8 джаве обойтись

Все равно этот TRY/CATCH верхнего уровня существует и он печатает стек трейс в консоль.

почти как panic в го)

То есть любой TRY/CATCH внутри кода — это code smell. Это что-то значит не очень хорошо сделано.

В идеале их быть не должно, и весь код должен выглядеть так, будто он никогда не падает. И везде куча THROW. Это утопия, но к ней нужно стремиться)

Все равно этот TRY/CATCH верхнего уровня существует и он печатает стек трейс в консоль.

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

В идеале их быть не должно, и весь код должен выглядеть так, будто он никогда не падает. И везде куча THROW. Это утопия, но к ней нужно стремиться)

Понятно. Буду код свой рефакторить и подставлять throw ?так что насчёт optional?

Либо по всему коду вместо нуллов будут трай-кетчи

В идеале их быть не должно, и весь код должен выглядеть так, будто он никогда не падает. И везде куча THROW. Это утопия, но к ней нужно стремиться)

И runtime эксепшены не кидать? Только чекд пробрасывать?

И runtime эксепшены не кидать? Только чекд пробрасывать?

Да, в идеале.

вообще throw должны быть тогда только на edge кейсах, когда закончилось место на диске, пропала сеть и тд

Понятно. Буду код свой рефакторить и подставлять throw ?так что насчёт optional?

Optional — это костыль. Я бы рекомендовал делать кастомные классы под задачу каждую.

Использование рантайм эксепшенов считается хорошей практикой

вообще throw должны быть тогда только на edge кейсах, когда закончилось место на диске, пропала сеть и тд

Не только. Если входящие данные бракованные, допустим.

Почему Егор ты считаешь их плохими?

Да, в идеале.

это ведет к большому холивару

Почему Егор ты считаешь их плохими?

Я вот здесь описал это: http://www.yegor256.com/2015/07/28/checked-vs-unchecked-exceptions.html

В идеале их быть не должно, и весь код должен выглядеть так, будто он никогда не падает. И везде куча THROW. Это утопия, но к ней нужно стремиться)

ну кстати в спринг приложении правильно настроенном так и есть

Кстати, коллеги, у меня есть свой канал в Телеграме (там, правда, на английском только), добро пожаловать: https://t.me/joinchat/AAAAAEJFMRzsRTRxM3ec6A

есть общий перехватчик для разных видов исключений, там описывается что и как делать

ну кстати в спринг приложении правильно настроенном так и есть

Да, в приложении да. Но внутри самого спринга — все плохо.

Не только. Если входящие данные бракованные, допустим.

спорно. при кривых входящих данных просто сообщить в обратную сторону об этом и все, без бросания эксепшенов

спорно. при кривых входящих данных просто сообщить в обратную сторону об этом и все, без бросания эксепшенов

Как сообщить?)) NULL?

400й ошибкой

как вариант

Или LOGGER.error()?

как вариант

Ну так это THROW

Особенно отлично checked exceptions выглядели когда при чтении файла в finally вызываешь close и это оборачиваешь в try catch... лепота

Очень читабельный код

Очень читабельный код

А зачем оборачиваешь?

Особенно отлично checked exceptions выглядели когда при чтении файла в finally вызываешь close и это оборачиваешь в try catch... лепота

когда пишешь на java < 1.7

Да именно перед autoclosable

Особенно отлично checked exceptions выглядели когда при чтении файла в finally вызываешь close и это оборачиваешь в try catch... лепота

а зачем в finally close? а если файл не был открыт?

а зачем в finally close? а если файл не был открыт?

так нужно будет еще проверить был ли открыт

так нужно будет еще проверить был ли открыт

и это действительно будет читабельно?)

и это действительно будет читабельно?)

можно использовать Lombok. @Cleanup

можно использовать Lombok. @Cleanup

через стримы можно от try/catch/finally избавиться

одним только throw

По моему так лучше? public static List<String> readFile(String path) throws IOException { return Files.lines(Paths.get((path)), StandardCharsets.UTF_8) .collect(Collectors.toList()); }

Привет! У меня такая проблема с сценбилдером, может кто знает че можно сделать? )

Пожалуйста, подскажите, кто знает...