Почему нельзя возвращать NULL?

[@alexander_brun]

Всю пандемию возвращал null, теперь коллекторы названивают...

[@LionKing-qp1lk]

Посмотри кузнецова, научись экзепшона всем вставлять

[@Mirloom]

Так можно и П.Е получить)

[@LobanovSpace]

Вахах

[@LedoCool1]

@@LionKing-qp1lk нелюбители исключений уже идут за вами.

[@CarelessPossum]

garbage collector'ы

[@ОлегЛитвиненко-о5з]

- Микола, слыхав, як паскали наш null называють? - Як? - Nil! Поубивав би гадів!

[@evgenasd8892]

Он так и называется в паскале

[@ОлегЛитвиненко-о5з]

Avazart my bad😂

[@ivanskorokhod2959]

Олег Литвиненко в Свифте тоже nil. Я кстате тоже целую лекцию по этому поводу записал

[@listenheart5967]

на lua тоже

[@HannibalLecter-w3r]

да и в golang

[@IPWchild]

Не возвращай нал, возвращай безнал!

[@sergeimenshikov8611]

Когда пацики с района стреляют сигаретку, а ты, вместо ответа "не курю", падаешь и притворяешься мёртвым. добавлено: Забыл, ещё можно отдать им пустую пачку)

[@maxlich9139]

а исключение - это что в таком случае?)

[@daniilpalii6743]

@@maxlich9139 , падение же

[@maxlich9139]

@@daniilpalii6743 да это вроде null

[@sergeimenshikov8611]

@@maxlich9139 не, нул - это ответить "нету сижек". Исключение - упасть.

[@RossiYek]

Sergei Menshikov нет, исключение - это дать ему по башке и сказать: разберись в своих ошибках.

[@199aa]

Однажды русский программист из Калифорнийской компании вернул «zhopa», вместо Null. Всем понравилось, стали использовать. Потом стали нумеровать zhopa1, zhopa2, когда просто zhopa было недостаточно. Как-то звонят из Тайваня, говорят остановился весь завод, мы не понимаем из-за чего - даёт ошибку zhopa37 !

[@АлексейСалихов-з4ч]

Ты что-то перепутал. Ошибку zhopa37 выдавал сервер Диабло3 на релизе.

[@alsu666]

Однажды русские программисты из Германии, ночью, не зная как назвать методы, назвали их xyinja1, xyinja2. Так никто и не возражал.

[@199aa]

Теперь буду вместо Null возвращать «Sergey Nemchinskiy»

[@drKatzman]

NemchinskyDislikesNullException

[@pompei2]

SergeyNemchinskiyException

[@undefined-n5v]

А если булево, то NotNemchinskyException

[@sergeyg436]

Лучше ссылку на это видео

[@schrodingers_kater]

😂

[@lego12239nn]

Ждём следующий выпуск - "почему нельзя возвращать -1".

[@MikhailKolesnikov]

Почему любой стейт надо в енум, даже если там только он/офф

[@TeppopucT]

@@MikhailKolesnikov потому что любим обмзаться ооп

[@0imax]

@@TeppopucT enum - ни разу не ооп, просто превращение цифр в читаемый вид и контроль за тем, чтобы не засунули туда то, чего там быть не может. Внутри-то там всё-равно цифры живут.

[@0imax]

@@MikhailKolesnikov Чтобы код был красивый. Енум не жрёт ресурсов, он просто даёт бОльшую свободу и контроль, чем если делать то же самое через константы.

[@Mike19910711]

В Си, например, вообще нет эксепшонов. Там функции либо через возвращаемое значение какой-то код возвращают (типа 0 - всё норм; отличное от 0 значение - какая-то ошибка и т.д.); либо в функцию в качестве параметра передаётся указатель на int, в который функция выводит код ошибки.

[@BukasovMaxim]

1) Тема Optional не раскрыта :) 2) Еще можно было бы акцентировать внимание на том, что если есть метод, который может найти и вернуть *несколько* объектов, а может и ни одного (0..*), то в случае если не нашёл ничего, то обязательно нужно возвращать пустую коллекцию (или пустой массив), а не тупо null "для экономии памяти". А то видел я такое как-то. В результате вместо обычного итератора, который для 0 объектов просто сработал бы 0 раз, приходилось писать if+итератор. P.S. <a href="#" class="seekto" data-time="535">8:55</a> "... если каждый метод на входе будет проверять не null ли все его 20 параметров..." - явная проверка параметров *публичных* методов на null (а точнее не конкретно на null, а вообще на корректность) является хорошим тоном при разработке API: у публичного метода должна быть предусмотрена "защита от дурака".

[@linkernick5379]

Да, тоже ждал, когда будет речь об Optional и - о, боже, нет! - о монадах, но видимо Сергей слишком Star.

[@TwilightSun32]

так чего далеко ходить, в жабаскрипте так штатный match от строки работает. типа если ничо не нашел возвращает undefined. какая религия запрещает возвращать пустой массив - ума не приложу. в итоге условия вставлять надо (да, иногда это 4 символа лишних но некрасиво же).

[@БезКомментариев-х4м]

@@TwilightSun32 Тоже в первую очередь вспоминается match из JS. Он возвращает null, а не undefined. Но к нему претензии только с точки зрения неудобств. Это не значит, что никакая функция не должна возвращать null. Видел такое решение, и сам перенял: ( s.match(…) *|| [ ]* ) - то есть в любом случае возвращается массив, это заметно упрощает алгоритмы.

[@TwilightSun32]

@@БезКомментариев-х4м да, я именно такую запись и имел ввиду когда писал про четыре символа. То что синтаксис позволяет сделать проверку краткой не отменяет же её наличия.

[@ИльясМаметов-и1о]

Он хотел сказать Optional но у него получилось Опшены :D ну ладно, и на том спасибо)

[@Украина-й5к]

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

[@LobanovSpace]

Кек

[@inglevir]

Типичный медлннный фейл :)

[@dreyktroll4490]

Там есть еще одна итерация. Поклейщики все валят на мебельщиков, а им похеру, потому как форматная пила пилит только прямо. И мебель будет состоять из прямых линий. И в конце заказчик "а чой та у миня тута щель с палец, между меблей и стеной, и такая кривая", а исполнитель мебели "хз, у строителей надо спрашивать".

[@Kudriako]

Это пример, когда эксепшен проскакивает вверх по коллстеку, но каждый метод "считает", что обработать должны еще выше. А потом все приложение крешится.

[@drovoseg]

Допустим, у класса User есть поле с типом Group которое может быть пустое. У Group поле title и другие. Нам нужно вывести список юзеров с названиями их групп. Как быть без null? Возвращать вместо группы объект типа Group с пустым полем title? Это еще больше багов породит, причем намного хуже чем NPE, например в БД добавится пустая строка. И как по сети передать, тому же фронту? Фронт получит какой-то объект с пустым title, ему это дикое условие проверять надо будет вместо простого == null.

[@grommaks]

Ну тут была больше речь о возврате null если не удалось посчитать или загрузить данные из метода / сервиса. Что то не получилось, выкинь исключение определенного типа. Суть видео можно было свести к тому, что в интерфейсе можно перечислить положительный результат работы метода и все возможные исключения. Null не дает понимания о природе ошибки

[@drovoseg]

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

[@grommaks]

@@drovoseg в этом случае null это нормально

[@askolit1458]

@@drovoseg в чем проблема вернуть пустой масив групп? Если их нет? На фронте проверят через groups.length!==0

[@SergeyNemchinskiy]

использовать паттерн NullObject. Я же рассказывал :)

[@baratorch]

c++: постоянно использую возвращение nullptr в методах/функциях типа FindSomething(). Очень удобно. И когда это Something не найдено - это один из штатных вариантов, не требующий никаких эксэпшнов. В стандартных с++ контейнерах метод find возвращает какой-нить итератор end() в котором связанный указатель на Something равен nullptr. Какая тут принципиальная разница? Кроме того что без лишней конструкции в виде итератора - удобнее. NullObject - это же по смыслу то же что и NULL, нам все равно для него нужно будет писать код отличный от случая с норм объектом типа if (NullObject != FindObject()) ... ручками в клиентском коде. И если такой NullObject заполненный дефолтными значениями попадет потом в какой-то список, чем это будет лучше попадания NULL? Уж лучше пусть прога упадет при обращении к нулевому указателю, чем не упадет и будет производить какие-то (рушащие логику) операции с дефолтными значениями NullObject, считая их правильными значениями полноценного Object.

[@madcalm2024]

NullPtr - смарт-указтель, он прямо говорит что null в нем неслучайное значение

[@alexeylesnov8203]

Краткий итог всего видео: Рубисты молчать.

[@LobanovSpace]

:D

[@KostiaBazrov]

​@Глядач че бьля7

[@itcloudguy]

Гоферам тоже заткнуться! :)

[@chakchaky8521]

А в кристале как удобно с Nil работать... Видео дичька беспонтовая. Если обизяна сидит и не ждёт nil от выборки - ну кто тут её доктор? фу короче. Старая дичь.

[@alexanderskusnov5119]

Не знаю про Ruby, но если это функциональное программирование, то в Haskell это норма: поиск в словаре - результат Maybe, т.е. или Nothing (ничего не найдено), или значение в обёртке Just.

[@dvdrelin]

Спорный вопрос. Обкладывать все вызовы try-catch? Что ожидать? Какой крутизны должен быть стек catch-a Или другое - ловиться в catch наверху и разруливать стектрейс? Что мешает использовать ?? .? подводя к дефолту/nullObject если прям очень надо?

[@levonminasian6090]

Сергей, добрый день. Полностью согласен с тем, что вы сказали в видео. Однако всегда интересовал вопрос: почему когда мы пытаемся в Hibernate достать из базы поле с несуществующим id, мы получаем просто null вместо exception? Или таким фреймворкам возвращать null можно?

[@oshastitko]

не знаю, как в Hipernate , но в Entity Framework есть метод First(), который вернёт эксепшн, а есть FirstOrDefault(), который вернёт нул. По-моему, логично

[@universeunity9970]

@@oshastitko В гибере есть всё то же самое, можно вернуть null, можно exception)

[@yegorsk97]

А если сериализуется JSON и у пользователя есть поле которое не установлено, значение его null

[@XOTAbGRO]

C# 8.0 добавил понятие nullable (ссылочные типы, допускающие значение null) и сделал объекты как бы не допускающими null. И теперь почвилось куча предупреждений в местах, где идёт обращение без проверки на нуль или передача таких значений в методы без это1 поддержки. Стало удобнее. Теперь, если твой метод всё таки может вернуть нуль, то ты добавляешь знак вопроса к имени метода.

[@TheSyntime]

Логика нарушена. Почему, если возвращается null, то нужно переименовать метод в getStudentOrNull, а если выбрасывается эксепшон, то метод не нужно назвать getStudentOrThrowException?

[@handleftman]

по идеи если на метод повесить throws то его не нужно так называть?

[@redeyes256]

Потому что компилятор заставит тебя его явно обработать. А о том, что метод может возвращать Null программист мог не знать или забыть

[@Gimli_Dwarf]

@@redeyes256 чего? Хотя да про указатели оказывается нам уже знать не надо

[@TheSyntime]

@@redeyes256 Это к сожалению проблема компиляторов и самих языков, потому что он также должен заставить обработать Null, если он там возможен

[@redeyes256]

@@Gimli_Dwarf не понял к чему это вообще написано и причем здесь указатели

[@kirillkir6268]

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

[@0imax]

Тут уже надо конкретный случай рассматривать. Возможно, то, что в map может не оказаться объекта - это следствие неправильной архитектуры, и там вполне подошли бы nullObject-ы. Либо обращение к потенциальному источнику null-ов построить как-то иначе. Либо структура данных сделана не лучшим образом. Писал моды на Lua для одной игрушки - там весь код приходилось увешивать проверками, потому что, получив какой-то конкретный объект, не было никакой гарантии, что все поля у него заполнены, и при обращении к ним приходилось сначала проверять, "есть ли кто дома". Такой косяк был из-за архитектуры, а конкретно - нарушения LSP: в одних "объектах" все поля были заполнены нормальными данными, в других объектах, "наследованных" от того же родителя, часть полей могла просто не использоваться и быть равной nil (аналог null в lua). Будь архитектура правильной, "классы" бы расширялись, а не обрезались под конкретный случай, и лишних проверок не потребовалось бы.

[@drovoseg]

+1 Эксшепны для бизнес логики это тоже плохой паттерн

[@grommaks]

@@ВладСолнцев-м3г Естественно, но эксепшн имеет тип, может взлететь до первого catch, catch может отлавливать свой тип исключений, там хранится место ошибки. Т.е. вы пытаетесь загрузить продукт по id...зачем это делать если мы не уверены что такой id существует? Если продукт был удален в промежутках получения этого id клиентом и совершением запроса, то это исключение. Т.е. исключения не должны отрабатывать в штатном режиме...но они упрощают работу с кодом

[@zariumsheridan3488]

не знаю как в Жабке а в .Net если пытаешся из Dictionary вытащить что то при помощи dict[key] он кинет keyNotFound или что то в этом роде. для таких случаев есть TryGet

[@grommaks]

@@zariumsheridan3488 Незнаю как в жаба, но в php есть оператор @ чтобы заглушить вылетание ошибок и нотисов, а потом делаешь иф и выкидываеш исключение...чтобы все работало однородно. А в шарпах получается есть два вида try и tryGet?

[@Тимур-е7ы]

Вы посмотрите на API Java. Там огромное кол-во методов, которые выкидывают NULL, но это не особо волнует всех этих экспертов.

[@protiv_bio]

А кто сказал, что api java написано гениально? Смотришь в исходники, а там код как будто обфусцирован. Ну и совместимость, тянущуюся 25 лет, никто не отменял.

[@Тимур-е7ы]

@@protiv_bio если вы говорите о том что API Java написано ужасно и на нем не следует учиться, тогда можно считать разработчиков самой Java - больными людьми. Просто гениальный подход, пишем код на Java, но исходники стандартных либ не смотрим, т.к. там все сделано через одно место.

[@superspy2008]

@@protiv_bio на самом деле, если глянуть в код .NET - там тоже как будто обфускация. Но читая-читая-читая Рихтера или других толковых людей, начинаешь понимать, что это на самом деле очень сложная оптимизация. А где оптимизировать, если не в фреймворке

[@Igor-hz2gp]

тоже самое в Android SDK

[@woodzimierz9621]

За годы существования Java к самому ООП неоднократно менялись подходы, но обратная совместимость, как уже упоминали, ни кто не отменял.

[@alexsokol1086]

надеюсь следующее видео будет о том, почему нужно юзать котлин с null-safe и возвращать нулл

[@Таши-б5б]

Как будто мне не придётся проверять параметры на null, если в своих программах я перестану возвращать null. Есть же тысяча коллег, чьим кодом я пользуюсь.

[@АлександрМамзиков-х1у]

Да, это должно быть запрещено на уровне языка. Но тут речь о договорённостях.

[@beltar2]

@@АлександрМамзиков-х1у Отсутствие результата - это тоже результат, и религиозные фанатики могут идти лесом. Если вы засунете в функцию exception, то это не поменяет ничего, потому что вызывающий код точно так же ставится перед фактом необходимости проверки данного исключения, если оно вылетит. Т. е. все это по факту пустой треп о том, куда ставить проверку, но никак не отменяет самой проверки.

[@АлександрМамзиков-х1у]

@@beltar2 если функция возвращает null, бывает очень трудно найти причину ошибочного поведения, т.к. программа свалиться где-нибудь позже, иногда сильно позже. И там, в отладке, единственно, что вы увидите - это то, что пришёл null. Гораздо легче исправить ошибку, если программа вылетит непосредственно на ней. Отсутствие результата тоже имеет право на существование в некоторых сценариях, но тогда это должно быть сразу оговорено. Хорошо, если язык сам заставляет делать проверки в таких случаях.

[@beltar2]

@@АлександрМамзиков-х1у Тут я с вами соглашусь, что мерзкое окошко исключения сразу будет неплохо бодрить, однако данная ситуация все равно может быть автоматически распространена на любые вызовы, не нашел в коллекции что-то, вернул индекс -1. Это точно так же может пойти по системе, а может в следующей строке рвануть "List Index Out of Range" или как там оно в конкретном языке называется. В этом плане вероятность ухода ошибки дальше сильно снижается, т. к. если вы получали объект, то вы хотели с ним что-то сделать вот прям сейчас, а значит и по хоботу получите тут же. Кроме того, сама по себе ситуация, когда результата нет является первой, которую следует тестировать, если этого не делается, то тут извините, но говорить вообще не о чем. Но в целом обрабатывать исключения намного геморойнее, чем числовые коды (или enum), и делать это во всех случаях, когда возможно отсутствие результата, неважно в каком виде это сигнализируется, приятного мало. Как вариант, могу предложить что-то вроде BOOL TrySomething(int Id; out MyClass ReturnValue); Даже если язык позволяет не проверять вызов, сама по себе конструкция уже говорит: "Засунь меня в if".

[@АлександрМамзиков-х1у]

@@beltar2 исключение обрабатывать проще: достаточно обернуть в try самый верхний вызов. Но я говорил не об этом, а о статическом анализе. Например, если функция может вернуть null, компилятор должен заставит отработать такую ситуацию. В таком случае, у вас гарантировано не будет ошибок null reference. Например, такая фишка есть у typescript.

[@magadash9341]

Мордочка))))) Так мило)))) А вообще супер объяснения, огромное спасибо за работу!

[@tony-the-fox42]

Почему бы не возвращать какой-нибудь Optional тип, у которого будет свойство HasValue в значении True, если в Optional есть экземпляр нашего T, и False если нет? По моему идеальная вещь

[@Jdivanchik]

В тех случаях, где есть вероятность вернуть null да.

[@ilyapetrov5628]

Хочу добавить, что это вкусовщина и не стоит вовзодить это правило в абсолют, иногда NULL подходит лучше. Примеры: 1. Не найден DSN - дальнейшее выполнение программы не имеет смысла. 2. Не найден менеджер для клиента - ОК, с этим клиентом пока не работают менеджеры. Если в первом случае действительно лучше кинуть исключение, то во втором exception не подходит, так как: а) Это не ошибка, а эксепшены обычно кидают в случае ошибок б) Exception в данном случае тоже накладывает ограничение на клиентский код, более того он требует более громоздкой формы от клиента - try catch.

[@vladimirsadovnikov3797]

- Почему не кинуть exception из метода? - Потому что генерация exception - дорогая по времени операция. Что лучше? Objecx x = callMethod(); if (x == null) { // Мы знаем, что если метод не отработает, то вернётся null // handle error } try { Object x = callMethod(); } catch (SomeException x) { // Мы должны знать, какой exception ловить // Handle error } Что, сильно ситуация поменялась? Не думаю. Всё равно ошибки надо (сюрприз!) отрабатывать, от этого никуда не деться. - Код полезет в коллекцию и получает NPE. - Не выполнена конвенция о том, что в коллекции не могут храниться NULL-объекты. - Метод называется getSomethingByName(), а на самом деле должен называться getSomethingByNameOrReturnNull(); - А JAVADOC для чего существует? Что мешает в описании параметра написать "can return null if " - Вы получаете объект, который NULL; - Брехня. Вы получаете ССЫЛКУ, которая не ссылается на валидный instance объекта, а не объект. Нарушением ООП это не является от слова совсем. - Мы спускаемся с абстрактного мышления до уровня байтиков. - #&*%*! А машина чем оперирует? Абстрактным мышлением вашим или байтиками? Вы железяку программируете или какую-то абстрактную эфимерную среду? - Если вы упали сразу, то у программистов не возникает вопросов, как обработать этот Exception. - Ну, смотря как упали. Если упали на проде и повредили какие-то важные данные этим падением (например, вызвали инконсистентность). Вообще-то, падать, в принципе, нехорошо. - Если вы пишете серьёзную систему, весь основной блок находится в try/catch. - Ой не зарекайтесь. Если система подразумевает обработку ошибок при вызове каждого метода, никакой try/catch вас не спасёт. Мало того, жирный try/catch - это антипаттерн. Вы чему людей учите? Ну и т.д. и т.п.

[@homo-ergaster]

Вообще-то когда метод может кинуть Exception у него будет throws и компилятор прогера пошлет если он этот Exception не обработает или не перекинет. А если метод вернет null, то прогер вообще не в курсе вернул метод null или нет и может ли он вернуть null в принципе. "А машина чем оперирует". А компилятор на что? Не надо опускаться до процедурного программирования.

[@vladimirsadovnikov3797]

@@homo-ergaster Если exception наследуется от RuntimeException, то его упоминание в throws (сюрприз!) необязательно. Иначе везде бы были throws NullPointerException и тому подобные описания.

[@ВладимирБакулин-н8я]

Разница между null и эксепшеном в том, что в случае с эксепшеном ты знаешь ЧТО именно обрабатывать, а в случае с null нифига не знаешь. А если этот null перед тем как положить программу пролетел через 100500 методов, ты вообще хрен БЫСТРО разберёшься, как исправить баг (конечно, если твоё приложение - не калькулятор из десяти-пятнадцати файлов). А если ты ещё и кидаешь null из МНОГИХ методов, будешь сидеть и офигевать. Что? Откуда? Какого хрена? Я же всё правильно сделал. 🙃 А если дотуда дошёл эксепшен, ты смотришь - эксепшен такой-то, ага - вот эта хрень значит отвалилась - по-быренькому исправил и не получил сильно по башке (или как вариант, не встрял на многомиллионные издержки). В итоге что лучше: пожертвовать чуть больше памяти, или сидеть потом офигевать? Вопрос, конечно, философский. Но у меня есть подозрение, что тому, кто любит всё делать "руками", не нужны ООП-языки. Если памяти действительно так жалко, может нужно задуматься над тем, чтобы все проги сразу писать на ассемблере? 🙃

[@vladimirsadovnikov3797]

@@ВладимирБакулин-н8я То же самое можно сказать про RuntimeException, который пролетел через 10 методов. Вы точно также нифига не поймёте, что произошло и почему, потому что исходные данные, которые привели к ошибке, в описании к RuntimeException не сохранены. Вообще, если у вас возникают проблемы с пробросом NULL на 10 уровней вверх, то у вас, скорее всего, проблема с архитектурой вашего приложения. > по-быренькому исправил и не получил сильно по башке (или как вариант, не встрял на многомиллионные издержки) Ну, то есть, навернул костыль вместо того, чтобы родить фундаментальное решение, я правильно понимаю? > В итоге что лучше: пожертвовать чуть больше памяти, или сидеть потом офигевать Я предлагаю пожертвовать чуть больше мозгов. Ибо вы становитесь заложником LIE # 3: cellperformance.beyond3d.com/articles/2008/03/three-big-lies.html > все проги сразу писать на ассемблере? Проблема ассемблера только в одном: он не переносим между разными аппаратными архитектурами, и под каждую архитектуру придётся писать код по-новому. Для решения этой проблемы был придуман Си.

[@vladimirsadovnikov3797]

@@homo-ergaster LIE # 1 cellperformance.beyond3d.com/articles/2008/03/three-big-lies.html

[@АнтонВоронов-ы9ц]

<a href="#" class="seekto" data-time="3">0:03</a> - «Программист с большим стажем, директор …». <a href="#" class="seekto" data-time="32">0:32</a> - «Использование null в любой части кода - самая ужасная практика». <a href="#" class="seekto" data-time="60">1:00</a> - «Это точка зрения всех известным мне экспертов». Апелляция к большинству. <a href="#" class="seekto" data-time="85">1:25</a> - «Это один из блоков классической книги Боба Мартина, … Мартина Фаулера». Апелляция к авторитету. <a href="#" class="seekto" data-time="1045">17:25</a> вместо null предлагает выбрасывать исключение либо использовать паттерн null object. Игнорирует недостатки null object pattern и не рассматривает вариантов, где не подходит ни то, ни другое, но запрещает использовать null.

[@ClydeSimonSound]

Я не очень шарю в этом, но, насколько я понимаю, использование nullObject похоже на заклеивание дыры в стене обоями

[@now.7348]

"возврат НАЛА =откат=преступная коррупция" :))

[@ztepler]

Возможно мой вопрос чуть-чуть мимо темы, но я его очень хочу задать. Данный вопрос тесно связан с типами Python. Данный вопрос про "отсутствие значения" (None или NaN). Вероятно None и NULL это разные сущности, между ними явно есть отличия, но мне кажется в текущем контексте это похожие штуки. Что можно делать в том случае, когда какие-то части объекта могут иметь пустые (None) значения? То есть если наличие None (отсутствие значения) - это валидное состояние какого-то поля объекта, предусмотренное бизнес логикой? Такой кейс как раз приводит к этим проблемам что всё время нужно проверять, не является ли эта часть объекта None, но как этого избежать, если это часть бизнес задачи, мне непонятно. При это нельзя установить этот объект в дефолтное состояние, нужно контроллировать что в нём нет значения (иначе, например, при агрегации данных дефолтное значение будет искажать реальную картину). Может быть есть какие-то бест-практики? Может быть лучше для этого иметь какой-то специализированный объект (тот же самый numpy.nan?). Наверное как раз те самые None и NaN это и есть некоторая форма того самого NullObject, просто без дефолтного значения?

[@ni55an]

Ну вы даете, народ! Из-за какого-то NULL заставили человека писать видео на 20 минут

[@pompei2]

Да это ещё что - какой-то там NULL заставил создателя Java рвать на себе волосы.

[@LobanovSpace]

Хехех

[@0imax]

А мы-то что? Он первый начал!

[@alexlitsov9032]

Он только рад

[@kirillperov3843]

@@alexlitsov9032 Сергей Немчинский любит поболтать.

[@andrey.shpilevoy]

И весь код в try, а в catch перезапуск приложения, и вот тебе абузоустойчевость)

[@СилуанПоцелуев]

Что за бред? Почему null приравнивается к Exception или вообще к какой-то ошибке? Null это нормальное значение, которое показывает, например, что в мапе нет значения по этому ключу.

[@somethingfromrithim]

Null можно вернуть по какой угодно причине, а так если в словаре нету значения по данному ключу, то ты выкидываешь конкретный эксепшен, который тебе об этом сообщает. Это просто тупо понятнее, ч ее м выискивать, в каком конкретно месте выкинулся Null и что это означает

[@ДенисБондарчук-й8ю]

Окей, но чем тогда отличается возвращение null от выбрасывания исключения в тех кейсах когда программа должна продолжить свою работу Например аутентификация когда мы пытаемяся найти пользователя с определённым юзернеймом и от того, есть ли такой пользователь зависят дальнейшие действия , получается что вызывающий кот все равно должен обработать ситуацию только уже не с null, а с перехватлм исключения

[@Narryel]

<a href="#" class="seekto" data-time="1217">20:17</a> то есть возвращать бизнес невалидный обьект? мдаааааааа, fail-fast как говорится

[@justkrybik]

А с чего вдруг, в озвученном случае, это невалидный объект? Видимо давлением газов рвущегося пукана уши заложило...

[@systemify]

Потому что проверить возвращаемое значение проще, чем проверять поля этого значения

[@sergeykhairulin]

а потом мы еще этот объект мутировать будем, красота.

[@b3d4zz13]

Спасибо, с удовольствием послушал лекцию. Как оказалось, неосознанно уже натыкался натакие грабли неоднократно, но как именно чинить не знал, только ваоиант с дефолтными значениями.

[@Guitarist138]

А как же быть с null в БД? Али переводить всё на not null, дабы, не дайте боги, не написать лишнюю проверку?

[@protiv_bio]

Зависит от логики. Зачем null в БД, для полиморфизма? Тогда hibernate на себя берет ответственность следить за этими полями. Если бизнес-значение может быть null, тогда можно обернуть в Optional/кидать runtime exception на геттере поля, при этом в throws его еще указать.

[@qr46654]

Вернуть объект с пустыми полями?

[@stormvoid7017]

@@protiv_bio >обернуть в optional Чтобы получить nullpointer, но с другим названием 😂

[@protiv_bio]

@@stormvoid7017 когда ты получаешь optional и не проверяешь его, это как минимум странно. Когда ты получаешь Object, ты рассчитываешь, что там лежит object. Таковы правила, и не я их придумал.

[@Guitarist138]

@@protiv_bio то есть проверять не равенство null`у, а что там скажет isPresent? Великолепная логика. Меняем одну проверку на другую.

[@svetopolk]

Серега, переходи на JAVA 3, а именно KOTLIN, в котором узаконили возвращать null, потому что есть nonnull и nullable переменные. Бреслав отдельно подчеркивал, что null в котлине это тоже самое, что Optional.empty() в жаве, только без оберки и следовательно со всех точек зрения бесплатное. И не надо оборачивать никакими проверками на null и специально следить, что тебе запихнут в String null не надо (null запихнут только в String?), все на уровне компилятора. Пример: val name: String? = null val length: Int? = name?.length //тут будет null и можно вызывать у null объекта метод без всякой if (..!=null) обертки val length: Int = name?.length ?:0 // а тут ноль, кому не надо nullable переменных, тот и думает про default значение val length: Int = name!!.length //а тут выпадет исключение, для любителей кидать и ловить исключения

[@homo-ergaster]

Ээээх. Котлин, конечно, крут. Жаль что вакансий в энтерпрайзе на котлине кот наплакал (

[@svetopolk]

@@homo-ergaster дописывать и подерживать, конечно надо на JAVA, но все новые микросервисы мы на котлине начинаем. Мне кажется все так.

[@homo-ergaster]

@@svetopolk Ну не все. Если команда на Java и часть ее сопротивляется переходу на Kotlin, то хрен получится новое писать на нем.

[@svetopolk]

@@homo-ergaster если большая часть команды сопротивляется то действительно не переходят. Только весь вопрос - а сопротивляются ли? Это реальный кейс?

[@homo-ergaster]

@@svetopolk ну многие в команде его не знают и им в лом изучать, поэтому против. Потом в качестве IDE используем NetBeans, которая Kotlin не очень хорошо поддерживает, руководство не хочет покупать IDEA.

[@vad6525]

Приемлемо ли тогда иметь метод Find, который будет возвращать null? Например repository.FindById(20) возвращает null если данные не найдены. Конструкция простая и не вижу смысла ее усложнять.

[@iShredar]

Ты неверно понимаешь нэйминг. Если ты пытаешься получить что-то по уникальному полю, который определяется внутри вашей системы, то это всегда Get, иначе как вы смогли получить это что-то уникальное (например ID), если его ещё нет в системе. Если ты пишешь слово Find - то это должен быть поиск по не уникальным полям, а значит результатом будет коллекция. В случае если ничего не найдено, то это пустая коллекция. Единственный вариант с null - это поиск по уникальному внешнему ключу, который задаётся не вашей системой (например FindByExternalKey; Самый простор пример - это номер вашего паспорта, он уникален, но не вы создаёте/задаёте его, но вам нужно проверить зарегистрирован ли человек с таким номером паспорта у вас..). В данном случае вы пытаетесь проверить существует ли сведения о неком внешнем (не вашем) бизнес объекте, и этот случай близок к тому случаю, когда в видео говорилось что null допускается перед первым созданием объекта в некоторых архитектурных решениях.

[@vad6525]

​@@iShredar Любой ID может быть удален со временем, но остаться в логах или прилететь по api. Некоторые таблицы чистятся, за ненадобностью. ID может быть введен пользователем с UI при поиске. В этом случае он вполне может отсутствовать, так как пользователь может ошибиться. Не понятен пример про возврат пустой коллекции, я же спрашивал про repository.FindById, а не про Find

[@iShredar]

​@@vad6525 Если вопрос был именно про repository (или любой слой, который работает с хранением данных), то стоило это указать сразу в вопросе, а не в примере. В таком слое нэйминг является больше договорённостью внутри команды, но как правило он соответствует тому что используется в Business терминах/правилах. Такой слой доступа данных - это просто прослойка, предоставляющая данные из хранилища в понятном виде для вашего приложения. В таком случае, я считаю вполне нормально получить null для одиночного объекта, так как по сути его вернёт ваша база. Но этот слой не должен быть доступен напрямую с вашего UI, то есть между UI слоем и слоем предоставления данных (repository ) должна быть прослойка, которая преобразует эти "сырые" данные, в вид соответствующий Business терминам/правилам. И вот тут уже null не допустим. Если вы что-то запрашиваете по ID то, что было удалено или не существует вовсе - исключение. Осталось что-то в логах? - логи не часть приложения или бизнеса, логи это побочный продукт жизнедеятельности, для них свои правила работы; может прилететь по api? - проблема с архитектурой (не берём случаи, когда данные обрабатывались в некоторой задаче в момент удаления, тут банальное исключение) "Не понятен пример про возврат пустой коллекции" пусть нужно выполнить поиск по неуникальному полю, например FindStudentsByName, даже если ничего не найдено, не стоит возвращать null, правильно будет вернуть пустую коллекцию, что-то вроде new List ();

[@YanSokolovsky-o1t]

По-моему, прекрасно все упомянутые проблемы решены в Kotlin: - явное именование методов, например listOf(1, 2, 3).firstOrNull { it > 2 } - Null-safety: вы всегда твёрдо знаете (если речь не идёт о легаси-библиотеке) и вынуждены это учитывать, где может быть null, а где -- нет - Изящные синтаксические конструкции для обработки null'ов, вроде Elvis Operator.

[@samuro2ua]

Сергей, спасибо! Расскажи о тестировании для не тестировщиков. Какие виды тестов бывают? В каких случаях обязательно тестировать код, когда отложить на потом? И т. д.

[@mdfitumi]

Я не Сергей, но отвечу Самый базовый вид тестов - unit тесты. Ими тестирую функционал в пределах класса или модуля. Есть методология TDD, при которой сначала пишутся тесты, а потом под них подгоняется код (до его готовности). Писать или нет зависит от проекта, если вы работаете один, над небольшим проектом, то написанием тестов сильно усложните себе жизнь. С ростом проекта, в геометрической прогрессии возрастает шанс появления ошибок и регрессий, при внесении нового функционала. В таком сценарии наличие тестов сыграет вам на руку и позволит гораздо быстрее находить ошибки.

[@mdfitumi]

P.S. Написание качественных/несущих пользу тестов, требует качественного кода.

[@LerooryJenkins]

Очень классные и информативные видео, спасибо! Только смотрят их не только опытные разработчики, но и люди с маленьким опытом. В связи с чем было бы ещё круче вставлять, хотя бы, скрины с примерами кода для визуального понимания.

[@vladimirblagin3105]

Если бы там были скрины, было бы не все так однозначно :-)

[@IuriiVishnevskyi]

Осталось теперь запилить видео почему нельзя кидаться эксепшнами. И где взять тип Either. И зачем NULL object, если есть Optional.

[@errandir]

Optional закрывает конкретный случай, а null-объектов может быть несколько, если бизнесово их нужно различать.

[@Dimontius1]

Классный формат видосов!

[@forcharc]

А если писать на котлине? Есть ли смысл кидать exception, если тип возвращаемых данных заранее тебе говорит, будет null или нет?

[@nooftube2541]

Нет, конечно. В нормальный языках такой хрени нет :) Проблема только если это используются в связке с сырым jvm который плевать хотел на ненулабельность котлина.

[@it-6411]

Alex Smith через рефлекшн записать null в notnull поле)

[@alexandernifanin7366]

@@it-6411 так Gson любит делать.)

[@oshastitko]

Помимо всего прочего, бросание специфического эксепшена помимо возврата нулл имеет ещё одно преимущество: когда в методе мы работаем с 2-мя (или больше) объектами (например, связываем их) и любой из них нужно проверить на существование. Тогда возврат нула (если предполагается, что метод вообще должен что-то вернуть) не даёт понятия, какой из объектов не найден. С эксепшином же мы можем передать, какого из объекта нет. А также метод может не возвращать ничего и работать даже с одним объектом, требующим проверки на существование, нам же выше нужно сообщить, что метод по сути не выполнил ничего, с объектом ничего не произошло (по причине его отсутствия), а не просто "проглотить" типа ничего не произошло. То есть стратегия бросания эксепшена - действенная и универсальная

[@HybridWarARgungame]

Создавать NullObject это: тратить ресурсы на создание и удаление не нужного обьекта. И все равно по бизнес логике может быть необходимо проверить этот NullObject, пустой он или полный.

[@arturthoris7253]

расскажите это гуглу. onCreate(Bundle savedInstanceState) это тот самый lazy loading, но есть и другиие null например ссылка на активити и прочие компоненты

[@alexkononenko4862]

Да, это может стать холиварной темой. Но, поскольку исключения подтверждают правила, то в некоторых случаях возвращать нул полезно или даже необходимо. Например при реализации итератора и метода next().

[@4vvvalera]

Спасибо за видос. С исключением вместо возврата Null понятно, а как быть если это опциональное поле объекта и оно либо содержит ссылку на другой объект либо нет. Тут же по-любому нужно в клиентском коде if ставить или есть другие "лучшие практики"? Насчет варианта с Null-object - то не на все ж его можна зделать, некоторые объекты при этом могут стать не валидны (например какой может быть Null-object для гео-точки, она либо содержит координаты либо невалидна)

[@grommaks]

Конечно можно опциональгые поля делать...видео называется почему нельзя возвращать null...а не почему нельзя сохранять null 🐶 NullObject это как результат пустого ответа...и как правило если это модель, то getId вернет null...вот такой вот парадокс)

[@me2beats313]

есть класс Person ему сколько-то лет поле age но сколько - неизвестно значит оно == null null просто сообщает, что возраст на данный момент не определен (и это правда). это реальная, жизненная ситуация, ведь мы можем знать имя человека, но не знать его возраста. поэтому в любом случае нужно каким-то образом обрабатывать ситуацию, когда возраст ещё неизвестен, но мы уже что-то хотим с ним делать. и null кмк удобный и лаконичный способ для этого никогда не имел серьезных проблем с этим (хотя может потому, что не пишу на jаva?)

[@jelooJusta]

твой пример ничего общего с видео не имеет. Там про возврат null из метода, а не о свойстве обьекта, хотя в описанном случае практичнее указать age: -1

[@AnatolyPashmorha]

по классике тебе нужно создать новый ValueObject Age со значением Undefined каким-то. Ну, или Optional можно использовать. Вобще, это правильно, но не практично зачастую. Хотя, в видео речь больше об объектах (Person), а Age это все-таки Value, несколько иная сущность.

[@БезКомментариев-х4м]

@@jelooJusta Чем getProperty() не метод?

[@БезКомментариев-х4м]

@@jelooJusta Возраст age==0 обманывает. Мы должны помнить, что 0 подразумевает отсутствие.

[@БезКомментариев-х4м]

@@AnatolyPashmorha В видео вообще запрещается возвращать NULL, в любом случае

[@ipasenko]

С объектом понятно... А что с листами? Если вызываем что-то типа getAll(), но ничего не найдено. Что лучше: вернуть пустой лист или кидать not found?

[@alexandernifanin7366]

Хороший вопрос. Просто не слушать автора и фигачить по-старому. Он решил похоливарить.

[@Алексей-х4ж5т]

Долго слушал, и всё что я понял, так это то что автор сразу предлагает писать больше кода только ради того, чтобы не было NULL.

[@artemgoncharuk5174]

В JS (и не только) есть конструкция optional chaining которая прекрасно решает эту проблему. Object?.method?.() ?? ; вуаля, поведение аналогично паттерну NullObject ничего не произойдет и ошибки не будет. Так или иначе, что бы мы ни использовали всегда есть плата в виде каких-то проверок или перехватчиков, мы в любом случае не можем игнорировать отсутствие объекта в результате, это кейс который должен быть обработан, чем бы результат не являлся и какой бы паттерн мы не применили. Чтобы программисту было понятно что метод может вернуть null хорошо использовать аннотации и IDE которые могут это показать. Не вижу ничего страшного в современных языках использовать null, большинство решило эту проблему и умеет работать с null корректно.

[@mtokurow]

A как же стандартный JPA? Он-то как раз возвращает NULL, если в методе findById я впишу несуществующий ID, без всяких исключений и null object-ов. Или просто «quod licet Jovis non licet bovis»? :D

[@MikhailKolesnikov]

Файнд и Гет -- как бы намекают, что они про разное…

[@МаксимРуднев-ж4г]

Очередное классное видео от дяди Серёжи

[@f00b4r123]

GetObjectByNameOrThrowObjectNotFoundIfNotFound

[@zmeygavrilych]

Лаконичненько )

[@LosashExote]

Хорошо, тогда что делать, если функция вызывается во многих местах в коде, и каждый раз подобное событие ненахождения чего то должно выдавать немного разную ошибку в эксепшен? А в третьем месте это вообще должно быть выдано не как эксепшен, а как молчаливая запись ошибки в некий журнал событий? По мне так закладывать эксепшен в код метода общего назначения это какая то дичь.

[@radzewil]

Так а ексепшн не надо будет «обработать»?

[@ancient_ukr]

Надо, но если пропустишь обработку и возникнет ошибка, то будет понятно где она возникла.

[@radzewil]

Ancient Ukr если задача проверить найден ли елемент то тебе нужно вместо if писать блок перехвата сообщения, где еще нужно все равно писать if что б понять какое исключение прилетает. Да и вообще исключения нужны для исключений :) не нахождение элемента не есть исключение

[@ancient_ukr]

@@radzewil Для чого писати цей if, якщо можна написати "Все погано"😁 Якщо пишеш код для себе, то null повертати дуже зручно, не треба тих try-catch блоків, а просто робиш перевірку на null і все, також цей варіант краще з точки зору продуктивності, плюс ти знаєш що очікувати від свого коду. Друга справа якщо твій код будуть використовувати інші, тоді з'являться проблеми, які описав Сергій.

[@alexandernifanin7366]

@@ancient_ukr чего? Какого друга справа выкорчевати? 😃

[@alexthunderrex]

А данное утверждение актуально например для работы в Unreal Engine? Если я возвращаю nullptr, когда нет например персонажа по указателю 🤔

[@matyev-hcuabg]

Использование "NULL обьектов" в первой докрине заканчивается появлением в базе "пустых" записей через связи, которые затем вытягиваются в общем списке, и не только. Так что NULL обьект тоже зло, и использовать его нужно очень аккуратно, что бы не сохранить его в базу или где то еще.

[@lexlotar4847]

А можно рассказать о вариантах решения проблемы? По факту получается нужно весь вызывающий код оборачивать в try catch. А много кто говорил , что эт прям тоже не очень. И чем по ресурсоемкости отличается проверка на null и прерывание по try catch. Допустим я вибираю метод Single, и например по любой фигне, которую вбил пользователь кидается exception. Разве это также не накладывает ограничений на вызывающий код?

[@ЕгорВасякин-щ7в]

Иногда возвращать null - нормально, иногда выкидывать exception - нормально, а иногда дефолтные объекты возвращать тоже норм :) Нужно от бизнес-логики идти. Думаю, нужно видео с противоположными аргументами "Почему нужно возвращать NULL?", ну чтобы всесторонне тему разобрать, за и против) а то пока только с одной стороны) не хватает взгляда с двух сторон, это как у нормальных журналистов, которые с разных сторон вопрос освещают

[@yyyehor]

Хочу разобраться и понять как правильно. Реальный пример из проекта: в приложении есть уроки, они идут по порядку - в базе поле 'sort_order' (1, 2, 3 и т.д.). На странице урока есть карточки предыдущего урока и следующего урока. На бэке есть методы getPreviousLesson() и getNextLesson(). В моей реализации я делаю запрос в базу ...where 'sort_order' - 1... для предыдущего урока и ...where 'sort_order' + 1... для следующего. И возвращаю null, если предыдущего или следующего урока нет. Соответственно на фронте стоит if с проверкой есть ли следующий/предыдущий урок, если есть, то рисую карточку с уроком, если нет, то не рисую. Как-то эксепшин тут будто не в тему, а пустой объект урока вернуть не могу, т.к. куча реквайред полей. Как правильно поступить в такой ситуации? P.s. язык PHP, если что

[@abrorabdullaev7837]

То есть я правильно уловил суть? Вместо null при ексепшне надо возвращать текст и стэк трейс вместо null или вообще не надо возвращать ничего? Вобщем Сергей мне кажется вы ушли слишком много в детали и теперь сложно понять ответ на вопрос: Что делать когда по привычке хочется вернуть null

[@grommaks]

При эксепшене возвращать эксепшн соответствующего типа...в js error соответствующего типа. Зачем искать сущность по id если наверняка не знаешь существует ли она. С другой стороны если нужно загрузить сущность, в которой не уверен, то грузи коллекцию с фильтрами...вернется пустой массив если нет результата. Поиск сущности по id должен вернуть сущность или исключение того типа изза которого это не удалось. Упала бд, нет в бд, мертвые локи, и т д

[@abrorabdullaev7837]

@@grommaks хорошо, это понятно, но это не решает проблему которого Сергей осветил, в любом случае клиентская сторона должна будет хендлить кейс когда сущность не найдено, с помощью null или ексепшном, вот тут я не понимаю, раз не надо возвращать null, то что надо возвращать что бы клиент был всегда спокоен, так как если клиенту все равно придётся хендлить такой случай тогда уже без разницы возвращается null или ексепшн, ну разве что более информативно представление

[@grommaks]

@@abrorabdullaev7837 Ну нет же, exception хендлить легче и можно это делать на десятки уровней выше. 1 вы завернули репозиторий в 5 декораторов, значит все 5 должны обработать случай с null иначе приложение упадет. Эксепшн полетит вверх мимо всех декораторов, и это же прекрасно. Тот кто делает декоратор, обрабатывает только позитивный кейс и не думает о негативных. 2. Представте что нужно вызвать несколько сервисов для одного действия...если хоть один упадет, то логаем и заканчиваем действие. То пишем try и пишем несколько действий подряд...пеервое действие возвращает первую модель и передает ее во второе действие и так далее...если вернется null то мы обязаны после каждого действия делать иф и прекратить эти действия...т.е. Будет еще 3 ифа и логики отказа в каждом...вместо одного catch с логикой отказа. Т.е. С exception на не нужно делать доп проверки, потому что это возможности языка. А работать с null как с объектом это уже критическая поломка. 3 клиентский код пишется гораздо и гораздо чаще. Работая и исключениями, все что вам нужно, это не ловить их и тогда уже вы будете возвращать исключения) разумеется ловить их не том уровне, где нужно обработать исключение или изменить тип исключения...т.е. Работы гораздо меньше чем кажется...а теперь представим null. В каждом клиенте должна быть проверка. Стектрейс обычного приложения может достигать 30 и более вложенностей. И каждая вложенность будет это проверять...

[@hrustalevdev]

Хорошее видео. Спасибо!

[@КакДела-п4ю]

Кидать эксепшн из геттера только потому что по переданному айдишнику ничего не нашлось? Пожалуй я не готов быть экспертом.

[@shitposting_box]

Так сказано же, что кидать исключение в случае, если по указанному айдишнику всегда 100% должно вернуться что-то, отличное от null, что в общем-то логично - если метод всегда должен возвращать объект, а не возвращает, то где-то проеб и лучше кинуть исключение

[@КакДела-п4ю]

@@shitposting_box Ааа, я понял, вместо простого нал, вернуть нал в обертке, может на уровне экспертов это и круто, но у ребят попроще точно все поломается когда они получат объект с нужным интерфейсом, но при этом полностью голый. Что значит "100% всегда что-то вернется "я не уловил, такое может быть только если метод параметров не принимает и всегда одно и тоже возвращает.

[@КакДела-п4ю]

Или если это чистая функция, но мы ведь про геттеры.

[@justkrybik]

@@КакДела-п4ю допустим, мы конструируем объект, скажем, автомобиль. В его конструкторе инициализируем двигатель, но бизнес правилами авто без двигателя не должно существовать... Ставить null и везде в клиентах автомобиля проверять его? Или бросить исключение и ловить его в коде обладающем знаниями о том что с этим исключением делать?

[@КакДела-п4ю]

@@justkrybik Я не люблю подобные примеры потому как они очень отдаленные, мы говорим не о уровне бизнес требований, а гораздо более мелком, хотя даже здесь я уже заранее знаю что однажды бизнес скажет: "А нет, все таки может быть авто без двигателя когда двигатель на кап ремонт вытащили". Вообще подобные ситуации уже давно решаются тайп хинтами, а мы обсуждаем предложение автора вообще никогда и ни при каких обстоятельствах не возвращать нал.

[@toxic-text]

Почему метод get(key) штатного HashMap возвращает null ? if key not find

[@viktor_beloff]

getSomethingOrThrowException, не?

[@ppmishapp]

getSomethingOrThrowExceptionIfNotFoundBecauseIDoNotWontReturnNull

[@MrRagday]

Подскажите, что такое "клиентский программист" в данном конетксте? Фронт-ендщик? Тогда как он использует методы из бекенда?

[@СергейМельников-л8ъ]

Нет, это не связано с разделением фронт/бек, это разделение вызывающего (клиентского) и вызываемого кода, в данном случае клиентами будут все вызывающие наш метод программисты

[@MrRagday]

@@СергейМельников-л8ъ спасибо!

[@alexanderchumachev3520]

как жить дальше если даже javax.persistence.EntityManager.find() возвращает null?

[@grommaks]

Это же другой слой приложения. Тут как бы про доменный слой больше говорилось...ну мне так показалось...наверно 🦊

[@alexanderchumachev3520]

WebDev. GromMax ну я так понял автора что в любом слое это плохо

[@grommaks]

@@alexanderchumachev3520 Я вам так скажу, если ваш домменный слой будет работать с классами фреймворка, то это путь к проблемам при обновлении. Нужно сделать адаптер, который уже эти null заменит на exception и использовать ваш адаптер во всем проекте. Когда фреймворк обновится...ваш адаптер сломается...но это всего одно место в проекте) Если вы делаете приложение калькулятор...то тут можно не заморачиваться. Вывод, не важно чтт делает фреймворк или библиотека. Сделайте адаптер и работайте с консистентным набором классов

[@alexanderchumachev3520]

WebDev. GromMax Мой каментарий был сарказм, я категорически не согласен что есть необходимость везде нулы поубивать. Фреймворк работает верно

[@Ioann48]

тогда почему std::map::find не называется findOrNotFind?

[@АлексейКорноухов-з7л]

Исключения на многих языках вроде как довольно дорогая ситуация, поэтому наверное не все следует реализовывать с помощью них. Но так конечно автор прав. Вообще в языках должно быть уже прямое указание, что там null быть не может, как в Swift.

[@robotE13]

Неважно дорогая или нет. На мой взгляд, тут другое ограничение. Исключения надо использовать только как исключения... сюрприз, да? То есть когда произошла реально ненормальная ситуация (ну например идет попытка активации несуществующей учетки, или БД недоступна, или чтение из файла завершилось ошибкой и т п). БЛ же на них строить - чистой воды безумие.

[@torburgmax]

@@robotE13 вот соглашусь. и глобально контракт нам говорит, может ли объект вернуть нал или ошибку. поэтому с этой точки зрения вообще никакой разницы нет, ошибку обработать только "дороже" с точки зрения написания кода

[@alex.perreras]

В одном из проектов у нас было решено делать повсеместную проверку обектов на @nullable. В итоге абсолютно все методы делают проверку Objects.requireNotNull() для всех параметров, который при ошибке кидает NPE. В результате у нас есть места где происходит по 15-20 вложенных вызовов методов в кадом для которых каждый параметр проверяется на not null - причем по 20 раз каждый парамметр..

[@viv81ster]

В magento возвращался null object и это хуже null потому что ты ожидаешь что вернулся кастомер какой-то по id и а у тебя пустой объект побежал по системе

[@lyloo6577]

хрен редьки не слаще, либо обвешиваешь все проверками на null, либо на null object )

[@sevkakovalchuk7672]

Это в какой Magento? В Magento-2 репозитории выбрасывают NoSuchEntityException, если пробовать достать несуществующий объект по ID или другому идентифицирующему полю (например email для кастомера). Если getList делать с searchCriteria, то всегда объект возвращается, но я не бы не назвал его NULL-объектом. Если ничего не найдено, то у него просто будет пустой массив items.

[@viv81ster]

@@sevkakovalchuk7672 Вот под рукой 2.3.3 но в более ранних тоже самое \Magento\Cms\Model\PageRepository public function getById($pageId) \Magento\Customer\Api\CustomerRepositoryInterface /** * Retrieve customer. * * @param string $email * @param int|null $websiteId * @return \Magento\Customer\Api\Data\CustomerInterface * @throws \Magento\Framework\Exception\NoSuchEntityException If customer with the specified email does not exist. * @throws \Magento\Framework\Exception\LocalizedException */ public function get($email, $websiteId = null); Да их полно

[@sevkakovalchuk7672]

@@viv81ster не понимаю Вас. Вот метод: /** * Load Page data by given Page Identity * * @param string $pageId * @return Page * @throws \Magento\Framework\Exception\NoSuchEntityException */ public function getById($pageId) { $page = $this->pageFactory->create(); $page->load($pageId); if (!$page->getId()) { throw new NoSuchEntityException(__('The CMS page with the "%1" ID doesn\'t exist.', $pageId)); } return $page; } он выбрасывает исключение. Так же как и CustomerRepository, это видно даже в заголовке у вас в комменте: @throws \Magento\Framework\Exception\NoSuchEntityException If customer with the specified email does not exist. Или вы про методы типа load()? Ну этот подход давно deprecated. Так же как и метод save(). Для загрузки и сохранения надо использовать Repository. Factory применяется когда надо создать новый объект, но в таком случае вам не надо делать load обычно.

[@viv81ster]

@@sevkakovalchuk7672 Возвращался, там стоит прошедшее в первой так точно Сейчас там переделали все Сорри я посмотрел на ваш вопрос и не понял.

[@LobanovSpace]

А кто знает, чем отличается ноль и нуль?

[@alexsanruscool]

Офигеть прервёмся на рекламу. У меня перед твоей рекламой в этот момент вылезло ещё две.

[@purplep3466]

adblocker

[@purplep3466]

на всех операционках есть, даже на iPhone спокойно есть способ блочить рекламу

[@0imax]

Претензии к ютубу - он сам решает, куда и сколько рекламы вставлять.

[@grommaks]

@@0imax Временные метки определяет автор видео, так было года два назад...что то поменялось?

[@0imax]

@@grommaks Ты включаешь монетизацию, а ютуб сам решает какую рекламу и в каком количестве ставить. Причём сейчас всё настолько печально, что в зависимости от контента монетизация может быть недоступна, например, если в видео есть просто демонстрация оружия (порой даже страйкбольного) или какая-нибудь жесть, пусть даже это исторические материалы. Ну а временнЫе метки, которые под полосой прокрутки - это уже автор делает, но на рекламу это вроде как не влияет.

[@alex-elkin]

Не возвращать null - отличный совет. Но решать это выбросом исключения.... Возвращая null нарушаем контракт метода (из сигнатуры непонятно, что можем вместо объекта вернуть нечто другое). Но выброс исключения разве не является еще большим нарушением контракта? Клиентский код объект ждет из сигнатуры метода, а не исключение.. Может ваше видео, конечно, о Java, где в сигнатуре явно пишется throws.

[@serhiis_]

давайте вместо out параметров бросать исключения - хорошая практика. Так же ксаиоми написан и тамагочи! На кой черт нужны параметры если есть исключения!!!

[@WalkHB2]

Полезное видео. К сожалению, "вершиной" программирования считается применение паттернов, при чем в таком формате, что чем больше паттернов использовал при написании модуля N - тем лучше. А вот об умении писать код без null, об умении писать код с минимальным количеством if (когда код не витвится на 100500 вариантов, а "течет" по одному маршруту) - почти никто не говорит. Ну и написание нескольких слоев авто-тестов (юнит, приемочные, интеграционные) должно быть по умолчанию, но, к сожалению, не везде они есть, и далеко не везде они покрывают весь функционал.

[@daniilpalii6743]

Что скажете про добавление методов `bool Exists(int id)` или `bool TryGet(int id, out Student student)`?

[@maxlich9139]

Для обработки null-ов сейчас в джаве, кстати, есть Optional-ы и Stream-ы. И при этом если ты работаешь с Optional-ами и Stream-ами, то чаще всего удобнее, когда из методов возвращаются null-ы, а не кидаются эксепшены (тем более - проверяемые).

[@АлексейРеволюция]

ResponseEntity с обработкой null-ов это вообще спокойная тема

[@maxlich9139]

@@АлексейРеволюция это что? Spring web mvc?

[@АлексейРеволюция]

@@maxlich9139 ага

[@maxlich9139]

@@АлексейРеволюция А ну это другое, понимать надо ))))

[@КонстантинФедуров]

А если метод обновляет существующие данные объекта. И мы можем же передать только измененные поля, и тогда в момент присваивания мы можем проверить является ли один из параметров null, и если он является то мы не изменяем это поля. Здесь получается null используется как у индусов)что можно сделать в данной ситуации?

[@lego12239nn]

Офигеть. А что обработка исключения чем-то будет отличать от проверки на NULL?

[@skeimor9129]

Исключение можно пробросить, исключение даёт больше информации. В случае Java ты даже всегда знаешь в каком месте исключение может быть. А если везде null возвращать, то у тебя обращение к любому объекту придется в иф заворачивать.

[@lego12239nn]

@@skeimor9129 Я не о том. Возвращать null везде не надо, но там где надо, его надо возвращать. Оборачивать все вызовы в try catch - это маразм. Делать это только в "одном месте" тоже не вариант. Исключения классная штука, но где-то проще, красивее и эффективнее if.

[@0imax]

Разница в том, какая ошибка вылетит и когда. В видео об этом сказано. Exception вылетит сразу же в том месте, где не нашёлся объект, и с поиском места ошибки не будет проблем. На null клиентский программист может просто не проверить (не будешь же весь код проверками набивать) и пустить объект дальше гулять по системе, и NPE тогда вылезет совсем в другом месте, там, где этого меньше всего ожидаешь. Или, что ещё хуже, будет вылезать при очень редких условиях, которые ещё надо суметь повторить, чтобы вызвать эту ошибку. И мало того, что сам по себе NPE неинформативен, так ещё и источник его появления задолбаешься искать. Грубо говоря, отказ от null в пользу исключений перекладывает обработку результатов невнимательности программистов на машину, чем упрощает им жизнь.

[@lego12239nn]

@@0imax > На null клиентский программист может просто не проверить И что ж теперь? Клиентский программист может много чего не сделать. Не тот порядок вызова, не те параметры, недопустимые диапазоны и т.п. > (не будешь же весь код проверками набивать) Здрасьте. Если надо, то будешь. > NPE тогда вылезет совсем в другом месте, там, где этого меньше всего ожидаешь. И что? Ну вылезет, ты увидишь, что вместо объекта NULL и просто пойдёшь в то место, где оно присваивалось. Какие проблемы? > И мало того, что сам по себе NPE неинформативен, так ещё и источник его появления задолбаешься искать. А что, java разве уже не выдаёт call trace? > Грубо говоря, отказ от null в пользу исключений перекладывает обработку результатов невнимательности программистов на машину, чем упрощает им жизнь. Вовсе нет. Исключения это хороший инструмент, но нужен он не так часто, как многие думают. А попытки решить проблемы криворуких программистов и убогой архитектуры через замены всего и вся на исключения, ведёт к ещё большим проблемам и опять же убогой архитектуре.

[@0imax]

@@lego12239nn > Клиентский программист может много чего не сделать Но это же не повод дополнительно вставлять ему NPE в колёса. Ну а чо, можно до кучи повесить на всё throws и пусть мучается оборачивает каждый вызов)) > Если надо, то будешь. Тем самым засирая код кучей ифов, чтобы проверить весь (все) пришедший(е) объект(ы). Иногда проще повесить try catch на всю работу с "подозрительным" объектом и не париться. > И что? Ну вылезет, ты увидишь, что вместо объекта NULL и просто пойдёшь в то место, где оно присваивалось. Какие проблемы? Проблема будет, если null пришёл в то место из сотни других мест и лежал там "до востребования". Поди найди потом, кто его туда положил. > попытки решить проблемы криворуких программистов и убогой архитектуры через замены всего и вся на исключения, ведёт к ещё большим проблемам и опять же убогой архитектуре Вот тут согласен. Исключения надо использовать там, где это действительно исключение, а не абсолютно равноправный с другими вариант исполнения. Ещё добавлю, что иногда необходимость в куче проверок на null как раз вызвана кривой архитектурой.

[@rucaua]

В php (в частности) есть строгая типизация возвращаемых значений, что решает вопрос передачи понимания, что метод может вернуть null. Ну и есть Null coalescing operator. Так что обработка полученного null не тянет кучи кода. В целом я согласен с Вашими выводами, конкретно смущает «никогда» и конкретно для php.

[@crutchmaster9637]

По тезисам. 1. Обработка null. Какая разница, будешь ты в вызывающем коде чекать на null или заворачивать каждый вызов в try-catch? Те же яйца только с боку, разница в дефолтном поведении. Кому-то будет удобнее, кому-то нет. 2. null - не тот объект. Ну сделают тебе суррогатный null из "правильного" типа объекта. Легче? Да нихера от этого не легче. 3. Параноя, ходишь и ждешь, что тебе подсунут null вместо того, чтобы работать. Проблемы недоязычков, типа java, которые типа строгие и типизированные, а на самом деле динамическая дрисня:) Хотя в каком- то ломбуке был @notNull, это ничего не работает как надо, ждите, когда сделают стандарт в жабку, который будет бить по копытам. 4. 200 агрументов проверять руками на null - долго. Проблемы говнокодеров, у которых по 200 агрументов в методе + проблемы недоязычка, который не умеет в метапрограммирование. 5. Fail fast. Не всегда null == fail. Если валиться быстро стало не нужно - такие же проблемы. То, что кодер не обработал null там где он не нужен - опять таки проблемы того, кто его не обработал. Что делать? 1.Throw. Тоже надо обрабатывать, исключения дорогие, километры сраных стектрейсов. 2.Null object. Суррогат. Использовать его не всегда можно, часто null'ы вообще не нужны и лучше грохнуться с npe, чем засунуть куда-нибудь кучу nullObject'ов. Ничего не решает, просо переносит проблему в другое место. Вывод. Жабка - говно, которое зачем-то позиционирует себя как строгий ооп язык. За 20 лет до сих пор не завезли нормальный null-check.

[@arthurfonzerelli6484]

Я так и не понял - вот есть некая дто, которая приходит в твое приложение из какой-то внешней системы с кучей полей, часть из которых может быть заполнена, а может быть и не заполнена. Например, дто клиентом, у которого может быть определенный документ, а может и не быть, может быть домашний телефон, а может и не быть и т.д. Обычно такие поля просто не заполняются и в итоге в приложение приходит дто с null в качестве этого поля. Если использовать некие заглушки вместо этих null с дефолтными полями, то как это будет выглядеть? Типа, если нет домашнего телефона, то какое у него значение по умолчанию? Значение "Отсутствует"? А как понять потом есть ли у него этот телефон? if(!phone.equals("Отсутствует))? Выглядит еще более костыльно, чем проверка на null. Это уже не говоря о том, что все эти dto генерятся обычно какими-то фреймворками, которые собирают их из json или xml, обычно такие фреймворки как раз и заполняют поле как null если не нашли его в исходном json/xml.

[@АмаякАбрамян-ю9э]

Null и undefined можно и нужно возвращать. Но только там где это нужно.

[@dmitryluchkin8424]

Здравствуйте Сергей, посмотрел ваше видео про курсы, заинтересовал подход. Посоветуйте, если я знаю core, сталкивался со спрингом, сталкивался с jdbc. Но уверенности в знаниях нет, имеет ли смысл сразу пойти на курс под названием Java EE? Реально ли с не очень большим запасом знаний, потянуть первые задания??

[@МихаилКрамер-н7ш]

Мне нравится, как в Laravel сделано. Есть метод find(), который вернёт null, и есть метод findOrFail(), который бросит исключение (которое, если не поймать, просто даёт 404-й статус ответа), если что-то не нашлось. Таким образом когда ты ожидаешь, что чего-то не будет, есть возможность не замарачиваться с try/catch, а если не ожидаешь - пишешь findOrFail(). Ну конечно надо доку прочитать, и знать.

[@arthurfonzerelli6484]

Ну да, и количество методов увеличивается в 2 раза ради ровно одного null.

[@alexeyolshevskiy1358]

Сергей как обойти ситуацию с null, если зависимости от того найден один или несколько обьектов зависит бизнес логика?

[@lexlotar4847]

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

[@АлександрМамзиков-х1у]

Это метод linq

[@pandaskeptic2937]

Как я понял вместо null стоит throw new Error(null); ?

[@АлександрМаксимович-м4р]

Взяли меня масленком на работу программистом. И нужно было написать парсер. И в одном из методов я возвращал null. Продакшн я положил...и причём это выяснилось уже во время релиза. Потому что null был в очень особенном случае. Было весело))) Поэтому null я вообще теперь стараюсь не трогать))))))

[@kirillkir6268]

Ну это больше вопрос к тестированию 😉

[@0imax]

О такой гипотетической ситуации я тут писал сторонникам возврата null, а вот и живой пример :)

[@lyloo6577]

Дурак тут тот кто сделал null таким особенным

[@0imax]

@@lyloo6577 Указатели в никуда были ещё в Си. В джава не стали придумывать что-то особенное.

[@lyloo6577]

@@0imax я имела ввиду, что не надо на такую повсеместно используемую штуку как null весить особенное поведение. Это примерно как человек который на "привет" отвечает ударом в морду )

[@allenwalker3514]

есть код которий может вернуть person->address->street. Не у всех есть адрес и даже стрит, тоесть будут нали (НО нали плохо или нет). Єсть клаент код метод которий принимает персон и должен вернуть адресс. Как тут без налов и ифов?

[@superspy2008]

пустая строка

[@allenwalker3514]

@@superspy2008 а если обжекта адрес нету? Пустая строка ето юзер так ввел или он ничево не вводил?

[@0imax]

@@allenwalker3514 Если пользователь ничего не вводил, то это и будет пустая строка в форме)

[@xlenchik]

каждый чих будем заворачивать в try except, а потом удивляться чего так все тормозит

[@mike_mi_mike]

Так что насчёт optional? Использовать его как альтернативу возврата null и паттерна Null Object?

[@saurontheblack6566]

а ниче что try catch обладает свойством замедлять работу кода в блоке try? Тяжело проверить на null? ох уж мой C#, ?? и ??= и ?. И как я понимаю try catch натянуть проще чем if? серьезно?

[@expurple]

Try catch натягивается не у клиента вокруг каждого вызова, а на верхнем уровне. Как Сергей сказал, если null это более-менее осмысленное и ожидаемое для клиента значение, то тогда try catch не надо.

[@lego12239nn]

@@expurple > Try catch натягивается не у клиента вокруг каждого вызова, а на верхнем уровне. Нет. Если это библиотека и у тебя своё мнение что делать если там не найдено(может надо закрыть дескриптор и т.п.), то именно что придётся оборачивать вызовы. Т.о. гемора больше, чем проверить на NULL.

[@lego12239nn]

@@expurple И как бы это нормально, когда прежде, чем использовать какое-то api, к нему читается дока. Может там быть NULL или нет, там должно быть написано.

[@saurontheblack6566]

@@expurple Не надо фанатично следовать надуманным правилам. Если объекта нет или ошибка то можно вернуть null и обработать спокойно в программе, если в функции может возникнуть больше одной ошибке и нам надо о них сообщить тогда есть смысл использовать try catch, но не надо забывать что код в перехватчике исполняется медленней чем без него, плюс есть много коротких конструкций для обработки null. Давайте тогда и для выхода из вложенности нескольких циклов использовать флаг, а не goto. Тот же goto и null это инструменты которые были созданы для работы и не использовать что то только из-за предвзятости это на мой взгляд очень странно.

[@pinpad5956]

@@saurontheblack6566 Логика просто топ. Если есть инструменты для проверки на нал, давайте его возвращать. Если есть таблетка от головной боли, давайте биться головой о стену. И кстати, если для вашего кода лучшее решение - это использовать go to, то это плохой код.

[@Mike19910711]

Иногда null - это не ошибка, а вполне себе ожидаемый результат. А чтобы клиент знал об этом, необходимо это написать, например, в javadoc. В том же Android API null в качестве результата часто юзается в некоторых методах. Например, когда ищешь View внутри ViewGroup через метод findViewById, null означает, что искомый View не найден в указанном ViewGroup; вполне себе логичный результат выполнения метода. Если бы вместо этого приходилось обрабатывать Exception, излишнего кода было бы очень много.

[@OstapenkoYevgeniy]

"Рубисты молчать, я вас знаю"... я не рубист и я их не знаю :) можно разъяснить? Мне правда интересно.

[@dmytrov8775]

В ruby nil - это полноценный объект со своими методам. При проверке он интерпретируется как фолс. И в рельсах возврат nil - нормальная практика)

[@OstapenkoYevgeniy]

@@dmytrov8775 всеравно я ничего не понял :) на досуге поюзаю ruby ) подскажи только куда копать, что бы понять )

[@savia6073]

А если в doc прописать, что может вернуться null, то не придется называть метод getByNameOrReturnNull

[@MrTheMaks]

Думал раз затрагиваем тему NUll, то стоит сказать и об использовании Optional, но Сергей решил его проигнорировать.

[@playerkilleryakutia9415]

Это что-то типа из разряда Enum?

[@MrTheMaks]

PlayerKiller Yakutia это надстройка над null. Вы можете на ютубе к примеру вбить и узнаете больше.

[@BtXFWkyZBtXFWkyZ]

Он же сказад про wrapper-классы (Future, Optional) как первый вариант

[@MrTheMaks]

Hamster Go получается я пропустил. Тогда извиняюсь.

[@protiv_bio]

@@GK-tw7nu конечно можно, ты ведь возвращаешь не null, а обертку, из которой ты не прочитаешь значение без get(), а get() нормальный программист без проверки делать не будет. Тут хоть бейся головой об стену, не забудешь проверить))

[@777android777]

Пример с программистами в разных офисах - просто 1-в-1 моя ситуация 3 дня назад. Метод getSTById(), кроме ожидаемого объекта также может возвращать null, без зазрения совести. А в клиенте по цепочке идет обращение к методу этого объекта. Думаю, комментарии излишни)) Сергей, Вам спасибо за труды! Очень полезные лекции.