Как правильно делать Error handling по "Clean Code" Роберта Мартина?
Вставка
- Опубліковано 19 чер 2024
- Обработка исключений, нетипичных ситуаций занимает гораздо больше времени чем разработка основного потока выполнений.
Не так страшны первые 80% работы как вторые 80%. Вторые 80% во многом состоят из Error handling. Об этом и поговорим.
Плейлист лекций по Clean Code, если вы пропустили - • Чистый код (clean code...
Приходите на менторинг PYTHON FoxmindEd!
PYTHON - bit.ly/2TgVaUn
Курсы для новичков:
JAVA - bit.ly/3veMJ9r
JAVA Start - bit.ly/2RLU5DM
C# START - bit.ly/3iwXzot
C#/.NET - bit.ly/3cyd63y
Инструментарий JAVA - bit.ly/2ShC94h
Automation QA (Java) - bit.ly/3pINhDy
ANDROID - bit.ly/3xiDB5f
FRONT-END - bit.ly/3vcaXRC
SALESFORCE Developer - bit.ly/3g9TJ2Y
UI/UX дизайн - bit.ly/3czhtLJ
GAME DEVELOPMENT - bit.ly/3pOCKGU
Обучение на проекте - bit.ly/3xe8h7q
Продвинутые курсы для состоявшихся девелоперов:
GRASP and GoF Design patterns - bit.ly/3veNkId
Enterprise patterns - bit.ly/3gbL5kL
Другие услуги:
Пробное собеседование - bit.ly/35airtK
Карьерная консультация - bit.ly/2Tllmgt
Сайт FoxmindEd: bit.ly/3wpIfhq
FoxmindEd в ФБ: / foxmindedco
FoxmindEd в Instagram: / foxminded.ua
FoxmindEd в VK: foxminded
Мой Telegram: t.me/nemchinskiyOnBusiness
Для деловых запросов: youtube@foxminded.com.ua
Тайминг:
00:00 - вступление Сергея Немчинского
00:24 - менторинг Python в FoxmindEd
01:26 - исключения, а не коды возврата
05:09 - блок try-catch-finally
07:39 - checked exceptions
11:03 - контекст в исключениях
14:22 - не возвращайте null
15:08 - не передавайте null в методы
#чистыйкод #немчинский #ityoutubersru
👨💻 После Senior ВСЕ? Как программисту развиваться после Senior и куда двигаться в айти? 👉 ua-cam.com/video/NnM1Od1TKdA/v-deo.html
Мало того что инфа очень полезная, так еще и визуал у данного видео идеальный! Цвета, фоны, футболка… пэрфэкто!
Чем больше программирую, тем ценнее становится каждое видео))
Спасибо Сергей Немчинский
Прекрасный курс лекций! Спасибо большое за знания! Если каждый будет применять принципы Clean Code, то как же просто будет сопровождать и модернизировать код!
Спасибо за видео, Сергей!
"не так страшны первые 80% работы как вторые 80%" (c)
а третьи 80% вообще запарные
Ауф
Сергей, сделайте, пожалуйста, плейлист на канале по клину. Многим было бы полезно
Спасибо. Был бы рад услышать еще больше про Clean Code )
люблю такие видосики, спасибо)
Спасибо, Сергей)
Велике дякую вам за це відео.
Дякую! Пояснюєте зрозуміліше, ніж в книзі)) курс по clean code 🔥🔥🔥
Чудесно!
13:12 - просто "null". Полностью согласен, это "сообщение" нереально бесит, из него хрен чего поймёшь
Когда-то писал на Си, вылетел системный эксепшн дословно "В памяти неизвестно что" 🤣🤣🤣
В 15 версии (Вроде как) уже нормально идет с описанием объекта, которое выбрасывает:
Exception in thread "main" java.lang.NullPointerException:
Cannot invoke "org.w3c.dom.Node.getChildNodes()" because
the return value of "org.w3c.dom.NodeList.item(int)" is null
at Unlucky.method(Unlucky.java:83)
Подписался 6 лет назад, сейчас поставил лайк и пошёл писать -говнокод- хороший код.
Вчера несколько часов искал материалы именно по этой теме, а с утра видео от Сергея. Сюрприз.
ИМХО - exception-ы удобны только для критических ошибок, при возникновении которых необходимо завершить программу или её часть. Для всего остального есть if-else, коллбэки и т.д. Особенно дико исключения выглядят в бизнес-коде, который должен легко читаться, как обычный человеческий язык - исключения торчат, как если бы из построенного здания торчали балки.
А насчёт глобального try-catch - вы серьезно? Ошибки проще всего обработать как можно ниже уровнем. Там, где они и могут возникнуть, так как зачастую от их возникновения зависит поведение программы. А чтобы корректно отреагировать на исключение, нужно иметь как можно больше контекстной информации.
*"Особенно дико исключения выглядят в бизнес-коде"*
Что именно дико выглядит в коде?
Можете посоветовать материалы по исключениям?
@@Das.Kleine.Krokodil either, optional, maybe
Спасибо
Класне відео. У вас є ще розбори й по іншим розділам (книгам) дядечки Боба? Якщо так то це дуже годний контент для програмістів, будь якого рівня... Для початківців як навчальний посібник від досвідченого ментора, а для прохаваних кодогенераторів як освіжаючий матеріал що варто робити а чого варто уникати. Дякую за інфу!
Сергей, расскажите про Optional, почему не рекомендуется его использовать в качестве аргумента функции?
я этого не говорил. наоборот - используйте
Кстати в джаве выйти из проги, бросив исключение и не обрабатывая его, не так просто - это исключение нужно будет зарегать вверх по всей цепочке вызовов
Буквально неделю назад писал метод, логика которого была такой: в сигнатуру передаются две линии, вернуть метод должен точку пересечения, если она есть, либо вернуть null, т.е. линии не пересекаются. Сделал возвращаемый тип Point?, и дополнительно в методе, в котором вызываю этот метод проверяю на null перед обработкой и кастом к Point
Так нужно было сделать метод isIntersected и вызывать его перед GetIntersectionPoint, а в самом методе кидать эксепшн
@@olegkot3362 , это же не эксепшн, а правильная логика (я просто привел реальный пример когда нужно вернуть null). Логика метода: либо вернуть Point? result = new Point(a1, a2) содержащий координаты пересечения, либо вернуть Point? result = null. В методе который вызывает этот метод у меня естественно стоит проверка на null перед преобразование просто в Point
@@apdgslfhsodbna это неверная архитектура, а реализовать логику можно разными методами (например, так как я выше написал). Если потом эту точку пересечения передадут через 100500 методов и в конце забудут проверку, то отследить откуда налл будет очень сложно
Ошибки программирования можно разделить на несколько типов. Понимание этих типов может помочь вам более эффективно выявлять и устранять проблемы в вашем коде. Вот некоторые распространенные типы ошибок программирования:
1. Синтаксические ошибки. Они возникают, когда код нарушает грамматические правила языка программирования. Например, использование неправильной пунктуации, ключевых слов с ошибками или неправильных типов данных.
2. Семантические ошибки. Эти ошибки связаны с логикой программы и возникают, когда код не выполняет предназначенную функцию. Это может быть связано с неверными алгоритмами, непониманием задачи или неправильным использованием функций и переменных.
3. Ошибки выполнения. Эти ошибки возникают во время выполнения программы. Они могут быть вызваны различными факторами, такими как деление на ноль, доступ к неопределенной переменной или попытка открыть несуществующий файл.
4. Логические ошибки. Эти ошибки связаны с неправильной реализацией алгоритма, что приводит к неверным результатам. Их трудно обнаружить, поскольку программа по-прежнему может компилироваться и работать без каких-либо проблем с синтаксисом или временем выполнения.
5. Разовые ошибки. Они возникают, когда программист неправильно вычисляет индекс массива или цикла, что приводит к неверным результатам или доступу к нераспределенной памяти.
6. Бесконечные ошибки цикла. Они возникают, когда в цикле нет условия, которое в конечном итоге станет ложным, в результате чего программа будет работать вечно.
7. Утечки памяти. Эти ошибки возникают, когда программе не удается освободить память, которая больше не нужна, что приводит к снижению производительности системы и потенциальному сбою программы.
8. Ошибки переполнения буфера. Они возникают, когда программа пытается сохранить в буфере больше данных, чем она может вместить, что приводит к непредсказуемому поведению и потенциальным уязвимостям безопасности.
9. Множество поврежденных ошибок. Эти ошибки возникают, когда память, выделенная в куче, не управляется должным образом, что приводит к непредсказуемому поведению и потенциальным сбоям.
10. Тупики. Они возникают, когда несколько потоков или процессов ждут друг друга, чтобы освободить ресурсы, в результате чего ни один из них не продолжает работу.
11. Утечки ресурсов. Эти ошибки возникают, когда программе не удается освободить ресурсы, такие как дескрипторы файлов, сетевые подключения или открытые потоки, что приводит к исчерпанию ресурсов и возможным сбоям.
Понимая эти типы ошибок программирования, разработчики могут принять необходимые меры предосторожности и внедрить правильные методы отладки, чтобы гарантировать, что их код не содержит ошибок и работает так, как задумано.
Курс по паттернам проектирования будет?)
Ловить надо те эксепшены, которые знаешь как обработать, остальные в главном хандлере на уровне приложения. Множественные try-catch влияют на перформанс, делают код медленнее.
все верно. Но главное - try catch делают код плохо читаемым
@@SergeyNemchinskiy Необходимое зло...
Что может являться главным хандлером в простом java веб приложении с сервлетами и jsp?
Передавать null (nil) можно и нужно при отсутствии ошибки в Go. Но это специфика именно этого языка)
А если я в методе (C#) специально делаю throw new Exception, а потом на верхнем уровне ловлю его. То это норм, или не стоит явно кидать исключение?
Если exception бросается при внештатной ситуации - норм, если это часть логики - антипаттерн (Control Flow Exceptions)
@@ex7903 спасибо
Про null параметры позновательно
Касательно перегрузки . Как быть если продукт использует ООП стиль в реализации на языке python ')
В .Net у коллекции List есть метод Find(predicate p) Он возвращает null. Если бы он возвращал Exception, то пришлось бы писать вместо проверки на null try catch, что не очень удобно, как мне кажется.
а в чем разница?
@@SergeyNemchinskiy принципиальной нет, что так эксепшен, что так, если забудешь обработать. Наверное дело вкуса. Единственное что с if впринципе не будет возбуждаться эксепшен.
С самого начала изучения Java считал Throw чем-то избыточным. Мне казалось, что это конструкция для "ленивых программистов" которые провоцировали других программистов писать лишний код. В моем понимании в любом случае нужно ловить любые исключения и специально обрабатывать те, с которыми понятно что делать. Оказалось я понимал Clean Code. :)
Шикарный топик. Но загар на груди не помешал бы.
да. пора в отпуск
Как считаете, если сейчас из айти сферы меня берут только в 1С😬 а мне бы хотелось скорее в разработку игр и приложений. Стоит ли идти куда берут, или работать на старой работе (не в сфере) и прокачивать в свободное время навыки, пока не возьмут куда хочется?
Я вообще не работал пока меня не взяли на интересную работу разработки игр и приложений. Всё своё время тратил на изучение и делал свои проекты.
@@igorgrischenko6518 блин, а может и правда уволиться нафиг, и сидеть учиться спокойно🤔
@@user-lh8om7bb7b найдёшь работу, которая тебе нравится и не проработаешь ни дня)
Сложный вопрос. Я перешёл в Asp.Net из 1С, давалось долго и с трудом. Все вечера и выходные уходили на освоение, и так полгода.
В 1С вы точно научитесь поддерживать приложения с крупной кодовой базой и работать с большими запросами. Архитектура написана уже за вас и весьма продуманно, вам только писать функционал поверх.
С другой стороны в 1С нет гита, вместо Кафок и RabbitMQ свой механизм обмена и вообще на всё свои эксклюзивные костыли.
Всё это потом больно и долго придётся доучивать.
Если речь идёт о разработке игр, скорее всего это язык со строгой типизацией, после 1С, Питона и ПХП тоже сразу не дастся, надо научиться мыслить типами и ООП.
Если платить будут не меньше, и свободное время освоение 1С не будет отбирать у вакансии, куда вы хотите, то, на мой взгляд, стоит идти. Но 1С это тоже немаленький пласт такой, это маловероятно.
Если 1С будет отбирать свободное время на доосвоение, то тут сложнее.
@@liamsmith7052 Бухгалтера у него время будут отбирать. Да и цифры гонять такое себе удовольствие. Пускай на фрилансе пилит мелкие заказы и практикуется.
Так я и не понял, что же по мнению Сергея нужно делать с checked exceptions. Если я должен отказаться от checked exceptions, приводите хотя бы пример какой-то, как я должен себя вести в ситуации когда нужно использовать условный FileInputStream. Мне наверх послать обработку ошибки или что?
Нужно поймать IOException в том методе, где используется код стандартной библиотеки, с помощью блока try catch -> обернуть в свое исключение, унаследованное от RuntimeException -> выбросить свое исключение
@@artemboiarshinov спасибо, все верно
@@artemboiarshinov спасибо за пояснение. В видео говорится о том, что блоки try catch засоряют код. А если этих стандартных библиотек использующих checked exceptions навалом в коде? Как вообще избежать использования checked exceptions если нужно работать с какими-нибудь стандартными библиотеками?
15:50 - а как это библиотека обновляется на проде? На прод обновления должны заезжать только контроллируемо, что уже предполагает предварительное тестирование функционала, который оказался затронут изменениями.
А может кто то плиз пояснить за checked vs unchecked exceptions? Я вот с Java на вы общаюсь, мне очень нравиться когда я пишу someLibrary.someMethod() IDE меня предупреждает о том что этот метод может вызвать исключения A, B, C и предлагает завернуть в try catch или «прокинуть» их дальше. Если же я такой же код пищу в C# я вообще без понятия что там может пойти не так. Когда говорится «не используйте checked exception” что собственно говоря подразумевается?
Огромное спасибо джаве что она не позволяет не заметить исключения )) Сколько раз это выручало ))
👍
Помню эти бесконечные try-catch нереально бесили в джава на андроид. Я хочу найти поле класса по имени, что там может сломаться? Нет же, вызывай через попытку.
Люди забывают, что исключения - про исключительные ситуации, начинают управлять потоком выполнения программы через исключения
Сергей, когда Swift курс?
Только сегодня наткнулся на коды возврата :D
надо же!
и испытал то чувство, когда наткнулся в коде на коды возврата, а потом посмотрел видео Сергея про то, что это зло, и так делать не надо
Получается что в каждом слое мы ловим только свои созданные ошибки и упаковываем их и отправляем в след слой. А ошибки незнакомые не упаковываем и просто отправляем дальше? Но ведь если случится именно Exception неизвестный то мы его не запакуем и его сложнее будет понять. Непонял етот момент…
Ну, я использую код возврата после того, как пришел ответ с сервера. Если он пришел с ошибкой - я возвращаю не объект, а строку "failed" и делаю проверку, если пришел "failed" то создать окно "что-то пошло не так" в самом приложении. Как мне эксепшен поможет окно создать?
Эксепшен поможет прокинуть ошибку напрямую от места возникновения проблемы до места решения этой проблемы, минуя промежуточные вызовы.
Например, вместо возврата строки "failed" и проверки её там наверху, можно просто бросить эксепшн, наверху в try блоке написать весь код так, будто всё прошло хорошо, а в catch блоке ловить все ошибки и выводить соответствующие окна.
Таким образом код нормального поведения программы отделяется от обработки ошибок, не захламляется ими. Плюс, если какая-то ошибка произошла, а обработчика нет - это не останется незамеченным.
@@0imax а, ты хочешь, чтобы я вместо возврата "failed" обернул код в try..catch и в ответе кидал эксепшен? Нуок, попробую
@@0imax спасибо, отличный вариант
Если unchecked exception нигде не обработался - никакой проблемы нет. Logback/Log4j его красиво отобразит в логах. Система мониторинга успешно пошлет весточку саппорту. Саппорт либо разберется сам, либо оставит таску на починку бага. Исключения нужны для исключительных ситуаций (пропала сеть между между БД и сервером, third-party не предупредив поменял контракт и парсинг упал, сервис не смог подняться и т.д).
Оборачивать в try-catch удобнее чем checked exception, но использовать механизм для восстановления после сбоя ради трекинга ошибки между слоями - костыль и оверинжиниринг. Ошибки бизнес логики, доменной модели моделировать на исключениях вредно. В Java появился Optional, как первый шаг в понимании этой проблемы.
Exceptions ради exceptions - это код ради кода, который увы пропагандируется мэтром Робертом Мартином.
посоветуйте материалы по исключениям
@@Das.Kleine.Krokodil попробуйте написать самостоятельно такие правила) могу посоветоватьткнигуч но она на Скале
Как правильно делать Error Handling по Klingon
Фух, слава богу он "всё ещё...")))
Футболка улётная, захотел такую
не хватает картинок с примерами. "трай кетч, не бросайте. а делайте троу..." - ну как без примера, то? Псевдокод подойдет
Я, конечно, понимаю что прошло уже два года, но на случай если данные ролики будут рефакториться :) , хотелось бы чтобы текст сопровождался каким-то иллюстративным материалом: картинки, примеры кода. Я, например, не очень въехал как предлагается строить иерархию исключений, при этом делая их непроверяемыми.
Я сейчас делаю так: к примеру, ошибка БД - я делаю RuntimeException и в сообщении пишу: "Database error, Query: 'здесь запрос, который был', Error: 'Record with ID 123 not found'".
Далее оно улетает наверх и отображается в 500 ошибке сервера (сам сервер продолжает работать ессно). У меня внутренний энтерпрайз, поэтому я не боюсь запалить конкретный запрос в БД.
Подозреваю что я что-то делаю неправильно, но как именно делать правильно - не понял. Оборачивать одно исключение в другое - понял. Как мне это поможет - не понял. Хотелось бы картинку :)
Ну и обработка ошибок в реактивном стэке (Spring WebFlux) это отдельная песня - ничего непонятно, но очень интересно и инфы очень мало. Если будет такая возможность - хотелось бы послушать.
А как же Golang? Насчёт возврата ошибки
А как же Rust, возврат ошибки, с проверкой компилятором, но без бойлерплейта?
Извините, но в последнее время я все больше изучаю OOA/OOD/OOP и наткнулся на две модели организации: богатая модель и анемичная. Считается, что анемичная модель плохая, поскольку "это не настоящий ООП". Не знаю насколько эта тема актуальна, вдруг Вы знаете ответ
Записывайтесь на курс Enterprise patterns, сможете вдоволь наговориться на эту тему)
Если коротко: анемичная модель содержит недостатки, но по факту более распространена, т.к. фреймворки заточены именно под нее
@@zatraun Спасибо большое! Я школьник, так что вряд ли мне деньги на это родители дадут
@@zatraun Просто меня настораживает фраза "ненастоящее ООП". А так, вроде бы, удобно: класс данных и классы обслуживания. Единственный минус в этом только то, что высокая связанность. (Извините, могу плохо разбираться - сам все это изучаю только неделю)
@@user-ey5xw2nx9s ого, многие годами программируют и не задумываются о подобных вещах)
Да, это удобно, поэтому так и распространено. Вся загвоздка в классах обслуживания - это по факту процедурный код, который сложно поддерживать и модифицировать.
Чтобы решить эту проблему индустрия пошла не в сторону богатой доменной модели, а в сторону микросервисной архитектуры - на самом высоком уровне разбить приложение на небольшие куски, которые будут достаточно просты, чтобы анемичная доменная модель с ними справилась.
@@zatraun Спасибо Вам за тему! Я всю неделю принципы SOLID учил :D
Ну, Сергей, коды возврата и исключения - это уже прошлый век! В по-настоящему современных языках, а С++ и Ява далеко не молоды, есть алгебраические типы, Option и Result обработку которых пропустить невозможно.
Это кроме Раста ещё где-то есть?
@@glebkolobov Optional в джаве уже есть лет 7. В Scala - Option, Either. Kotlin свободно дает реализовать Either. Часто в библиотеках вижу самописный аналог Either.
И тут я понял, что у меня не так в пет проектах)
"Меня все еще зовут Сергей Немчинский". Все услышу другое и сразу брошу исключение )
NonStillSergeyNemchinskiyException
15:10 - А как же аннотация @Nullable?
а что она решает? Фактически это просто макияж для той же кучи обвязки
Мені подобається підхід з Golang , коли функція повертає два значення - result, error
Throwable это насколько я помню, не интерфейс а родительский класс
Читаю на тизере NO CLEAN CODE
Помнится, в новых версиях Java улучшили NPE - он теперь показывает какой именно обьект в цепочке оказался null
все верно. нов се равно лучше делать так, как я написал
Куча срача в комментариях: 🙃
>Не освещены время и место отлавливания и обработки checked исключений. Фактически checked это проверяемые, предсказуемые и обрабатываемые компилятором исключения, а unchecked это, соответственно, непроверяемые, непредсказуемые и необрабатываемые во время компиляции исключения, т.е. то, что внезапно вылезет в уже запущенной программе. Ну ладно если это какой-то калькулятор количества оставшихся в шкафу конфеток. А если это какая-то система с высокой ценой за ошибку, типа банковской системы, или системы управления космическим кораблём (на орбиту-то запустить запустили, а потом внезапно оказалось, что где-то чего-то не хватает для полного счастья)? Зачем больно ловить лицом то, что можно было спокойно поймать ещё до запуска? Да, перестраховка, да много текста. Но иногда и перестраховка бывает полезной.
>JVM тоже хочет, чтобы checked исключения были пойманы и обработаны заранее, наверно ей так спокойнее жить.
>Checked исключения возникают в основном там, где шансы на сбой очень высокие, предсказуемо высокие. Ну т.е. если, например, внезапно нужно прочитать конкретный файл, и где-то дальше использовать его содержимое, а файла тупо нет, то сбой будет в 100% случаев. Т.е. да, это лишняя затычка в днище корабля, но это та лишняя затычка, отсутствие которой будет заметно ещё до того, как корабль отплывёт от причала и благополучно потонет.
>При необходимости можно получить новые checked исключения, расширив класс java.lang.Exception, если они вдруг где-то нужны.
>В Oracle Java Documentation написано дословно следующее: "If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception."
>Да, в других языках такой фигни может и не быть, но вопрос о том, так ли ужасны checked исключения сами по себе, или без них просто спокойнее тем, кто ранее привык к другим языкам, где их нет, это глубоко философский вопрос, в котором без поллитры не разобраться. 😁
Слушаю про null и получаю флешбеки по вордпресу где вызывают функцию и туда три параметра с null закидуют :)
Это фреймворк а не библиотека, а фреймворк диктует свою архитектуру и стиль. Причины такой реализации нужно спрашивать у прородителей.
@@vyacheslavgvorus3883 А где я писал, что вордпрес это библиотека? К чему это? Или вы ответ не тому комменту дали?
@@liubomyr-peteliuk Удивился удивлению. Не хотел задеть вашу самооценку.
@@vyacheslavgvorus3883 ахах, нечего не понял))
касательно checked exceptions и того почему их не используют. Java не задизайнена для высоконадежных систем, в том числе и хибернейт и много библиотек, поэтому в мире жавы принято кидать рантаймы. Если же всеже приходиться писать чтото надежное то рантайм ексепшины это боль (приблизительно как и динамическая типизация). Странно слышать такую катигоричную точку зрения от вроди как опытного дева.
Начинаю срач:
1. начнем с того, что промышленного кода на C# меньше чем на той же Java с этими "ненавистными" check exceptions
2. в JavaScript вообще нету exception. "Ну и парни как то работают" - такой себе аргумент
3. А теперь по делу
в Kotlin как и в C# все exceptions - unchecked
- всё было хорошо, код бросал exception, на верхнем уровне ловил, обрабатывал особым образом, тестами всё покрыто - конфетка
- происходит рефакторинг - и метод больше не бросает этот exception
в результате, т.к. проверки на уровне компилятора нет - то остался "специальный обработчик"
а это значит что остался код который НИКОГДА не выполнится
остались тесты для этого кода
а мы знаем по предыдущем видео от Сергея, что кол-во багов на кол-во строк кода - константа и не важно выполняется этот код или нет
Идеального варианта обработки ошибок пока не придумали, потому используем лучшее из того, что есть. Да и кроме обработчиков исключений, в больших системах всегда куча неиспользуемого кода, про который просто забыли, или который срабатывает раз в тысячу лет. Думаю, это допустимая плата за те плюсы, которые дают исключения по сравнению с кодами возврата.
В js есть исключения и их также можно ловить в try/catch. С ними есть некоторые особенности, но они есть и используются)
@@bubblesort6368 во блин. Как все поменялось :))))
Не совсем в тему. Исключения как вынужденная (и ресурсо-емкая) мера вместо компактных и наглядных кодов возврата имеют смысл (точнее безальтернативны) в функциональном коде - цепочке функций, возвращаюших один и тот же, но модифицированный каждой функцией, экземпляр объекта. В "вэбе" даже возникает потребность перехватывать генерацию исключений и возвращать клиентской стороне код возврата, с пояснениями ошибок если таковы были - это и людей пугать не будет,и случайно секретную или ДСП-инфу не выведет в стеке исключений
"Никаких кодов возврата в ООП языке". А как насчёт взаимодействия ООП кода с процедурным (например, вызов процедуры из БД)? Холивар по этой теме знатный, но как насчёт КлинКода?
"Никогда не возвращайте null". И что делать в случае, когда возвращается null из БД? Это ведь вполне допустимое состояние для реляционных БД.
Как вариант воспользоваться паттерном ValueObject
> А как насчёт взаимодействия ООП кода с процедурным
В библиотеке Skunk для работы с Postgres все ошибки последнего были записаные в sealed trait. Нечто подобное можно получить написав Enum на джаве, и использовать самописный Either. В КлинКод ответа не будет, потому что Роберт Мартин любит безтиповые языки, и считает что на всё нужно писать юнит тест.
> И что делать в случае, когда возвращается null из БД?
Либо Optional либо создать свой DbNull и писать логику согласно ему. Если пишите за деньги, то скорее всего будете использовать фреймворк, и он сам диктует как работать c null.
Непонятно для golang разработчика) какие экспшены...
для других программистов - а что Go - это язык? %)
{{'Error! ' + errorMsg}} - у меня вот такой лог в приложении, кто вкурсе что он значит ?
Писано индусом 😆
О, я же такое же писал три дня назад.