Как правильно делать Error handling по "Clean Code" Роберта Мартина?

[@SergeyNemchinskiy]

💪Новый поток advanced тренинга Enterprise patterns стартует 2.12 - go.foxminded.ua/4h492HW

[@denislopatkin6996]

Мало того что инфа очень полезная, так еще и визуал у данного видео идеальный! Цвета, фоны, футболка… пэрфэкто!

[@pseudouser55]

Чем больше программирую, тем ценнее становится каждое видео)) Спасибо Сергей Немчинский

[@Philip_Just]

"не так страшны первые 80% работы как вторые 80%" (c)

[@Николай-з4в7л]

а третьи 80% вообще запарные

[@ИТОШИРИН-ц6е]

Ауф

[@ДаниилСоловьев-э6ш]

Прекрасный курс лекций! Спасибо большое за знания! Если каждый будет применять принципы Clean Code, то как же просто будет сопровождать и модернизировать код!

[@yuriisurzhikov]

Сергей, сделайте, пожалуйста, плейлист на канале по клину. Многим было бы полезно

[@dDANiLiCHh]

Спасибо за видео, Сергей!

[@РоманК-к5к]

Дякую! Пояснюєте зрозуміліше, ніж в книзі)) курс по clean code 🔥🔥🔥

[@DoctorKrolic]

13:12 - просто "null". Полностью согласен, это "сообщение" нереально бесит, из него хрен чего поймёшь

[@apdgslfhsodbna]

Когда-то писал на Си, вылетел системный эксепшн дословно "В памяти неизвестно что" 🤣🤣🤣

[@KROL043]

В 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)

[@igorosetrov3569]

Спасибо. Был бы рад услышать еще больше про Clean Code )

[@ВиталийОвчаренко-т7й]

Ошибки программирования можно разделить на несколько типов. Понимание этих типов может помочь вам более эффективно выявлять и устранять проблемы в вашем коде. Вот некоторые распространенные типы ошибок программирования: 1. Синтаксические ошибки. Они возникают, когда код нарушает грамматические правила языка программирования. Например, использование неправильной пунктуации, ключевых слов с ошибками или неправильных типов данных. 2. Семантические ошибки. Эти ошибки связаны с логикой программы и возникают, когда код не выполняет предназначенную функцию. Это может быть связано с неверными алгоритмами, непониманием задачи или неправильным использованием функций и переменных. 3. Ошибки выполнения. Эти ошибки возникают во время выполнения программы. Они могут быть вызваны различными факторами, такими как деление на ноль, доступ к неопределенной переменной или попытка открыть несуществующий файл. 4. Логические ошибки. Эти ошибки связаны с неправильной реализацией алгоритма, что приводит к неверным результатам. Их трудно обнаружить, поскольку программа по-прежнему может компилироваться и работать без каких-либо проблем с синтаксисом или временем выполнения. 5. Разовые ошибки. Они возникают, когда программист неправильно вычисляет индекс массива или цикла, что приводит к неверным результатам или доступу к нераспределенной памяти. 6. Бесконечные ошибки цикла. Они возникают, когда в цикле нет условия, которое в конечном итоге станет ложным, в результате чего программа будет работать вечно. 7. Утечки памяти. Эти ошибки возникают, когда программе не удается освободить память, которая больше не нужна, что приводит к снижению производительности системы и потенциальному сбою программы. 8. Ошибки переполнения буфера. Они возникают, когда программа пытается сохранить в буфере больше данных, чем она может вместить, что приводит к непредсказуемому поведению и потенциальным уязвимостям безопасности. 9. Множество поврежденных ошибок. Эти ошибки возникают, когда память, выделенная в куче, не управляется должным образом, что приводит к непредсказуемому поведению и потенциальным сбоям. 10. Тупики. Они возникают, когда несколько потоков или процессов ждут друг друга, чтобы освободить ресурсы, в результате чего ни один из них не продолжает работу. 11. Утечки ресурсов. Эти ошибки возникают, когда программе не удается освободить ресурсы, такие как дескрипторы файлов, сетевые подключения или открытые потоки, что приводит к исчерпанию ресурсов и возможным сбоям. Понимая эти типы ошибок программирования, разработчики могут принять необходимые меры предосторожности и внедрить правильные методы отладки, чтобы гарантировать, что их код не содержит ошибок и работает так, как задумано.

[@SergeyNemchinskiy]

👨‍💻 После Senior ВСЕ? Как программисту развиваться после Senior и куда двигаться в айти? 👉 kzbin.info/www/bejne/hJ-wYoKaZrl-mqM

[@romantsyupryk3009]

Велике дякую вам за це відео.

[@kyryloshamraiev6289]

С самого начала изучения Java считал Throw чем-то избыточным. Мне казалось, что это конструкция для "ленивых программистов" которые провоцировали других программистов писать лишний код. В моем понимании в любом случае нужно ловить любые исключения и специально обрабатывать те, с которыми понятно что делать. Оказалось я понимал Clean Code. :)

[@Chybakut2004]

ИМХО - exception-ы удобны только для критических ошибок, при возникновении которых необходимо завершить программу или её часть. Для всего остального есть if-else, коллбэки и т.д. Особенно дико исключения выглядят в бизнес-коде, который должен легко читаться, как обычный человеческий язык - исключения торчат, как если бы из построенного здания торчали балки. А насчёт глобального try-catch - вы серьезно? Ошибки проще всего обработать как можно ниже уровнем. Там, где они и могут возникнуть, так как зачастую от их возникновения зависит поведение программы. А чтобы корректно отреагировать на исключение, нужно иметь как можно больше контекстной информации.

[@Das.Kleine.Krokodil]

*"Особенно дико исключения выглядят в бизнес-коде"* Что именно дико выглядит в коде? Можете посоветовать материалы по исключениям?

[@AlexPopov17]

@@Das.Kleine.Krokodil either, optional, maybe

[@vladimir2358]

Ловить надо те эксепшены, которые знаешь как обработать, остальные в главном хандлере на уровне приложения. Множественные try-catch влияют на перформанс, делают код медленнее.

[@SergeyNemchinskiy]

все верно. Но главное - try catch делают код плохо читаемым

[@vladimir2358]

@@SergeyNemchinskiy Необходимое зло...

[@СергейП-щ4ф]

Что может являться главным хандлером в простом java веб приложении с сервлетами и jsp?

[@max_mgtow]

Спасибо, Сергей)

[@0imax]

Подписался 6 лет назад, сейчас поставил лайк и пошёл писать -говнокод- хороший код.

[@СергейМ-к1ф]

В .Net у коллекции List есть метод Find(predicate p) Он возвращает null. Если бы он возвращал Exception, то пришлось бы писать вместо проверки на null try catch, что не очень удобно, как мне кажется.

[@SergeyNemchinskiy]

а в чем разница?

[@СергейМ-к1ф]

@@SergeyNemchinskiy принципиальной нет, что так эксепшен, что так, если забудешь обработать. Наверное дело вкуса. Единственное что с if впринципе не будет возбуждаться эксепшен.

[@apdgslfhsodbna]

Буквально неделю назад писал метод, логика которого была такой: в сигнатуру передаются две линии, вернуть метод должен точку пересечения, если она есть, либо вернуть null, т.е. линии не пересекаются. Сделал возвращаемый тип Point?, и дополнительно в методе, в котором вызываю этот метод проверяю на null перед обработкой и кастом к Point

[@olegkot3362]

Так нужно было сделать метод isIntersected и вызывать его перед GetIntersectionPoint, а в самом методе кидать эксепшн

[@apdgslfhsodbna]

@@olegkot3362 , это же не эксепшн, а правильная логика (я просто привел реальный пример когда нужно вернуть null). Логика метода: либо вернуть Point? result = new Point(a1, a2) содержащий координаты пересечения, либо вернуть Point? result = null. В методе который вызывает этот метод у меня естественно стоит проверка на null перед преобразование просто в Point

[@olegkot3362]

@@apdgslfhsodbna это неверная архитектура, а реализовать логику можно разными методами (например, так как я выше написал). Если потом эту точку пересечения передадут через 100500 методов и в конце забудут проверку, то отследить откуда налл будет очень сложно

[@dsalodki]

Про null параметры позновательно

[@djnecrowman]

Класне відео. У вас є ще розбори й по іншим розділам (книгам) дядечки Боба? Якщо так то це дуже годний контент для програмістів, будь якого рівня... Для початківців як навчальний посібник від досвідченого ментора, а для прохаваних кодогенераторів як освіжаючий матеріал що варто робити а чого варто уникати. Дякую за інфу!

[@madcalm2024]

Кстати в джаве выйти из проги, бросив исключение и не обрабатывая его, не так просто - это исключение нужно будет зарегать вверх по всей цепочке вызовов

[@shmeleu]

Шикарный топик. Но загар на груди не помешал бы.

[@SergeyNemchinskiy]

да. пора в отпуск

[@Vladimir_Java_dev]

15:50 - а как это библиотека обновляется на проде? На прод обновления должны заезжать только контроллируемо, что уже предполагает предварительное тестирование функционала, который оказался затронут изменениями.

[@oleksandrtolstoi5468]

Передавать null (nil) можно и нужно при отсутствии ошибки в Go. Но это специфика именно этого языка)

[@pavelkostetskiy7561]

люблю такие видосики, спасибо)

[@Degatino]

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

[@bolatmukashev2830]

Курс по паттернам проектирования будет?)

[@wowtk777]

Сергей, расскажите про Optional, почему не рекомендуется его использовать в качестве аргумента функции?

[@SergeyNemchinskiy]

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

[@feoktant]

Если unchecked exception нигде не обработался - никакой проблемы нет. Logback/Log4j его красиво отобразит в логах. Система мониторинга успешно пошлет весточку саппорту. Саппорт либо разберется сам, либо оставит таску на починку бага. Исключения нужны для исключительных ситуаций (пропала сеть между между БД и сервером, third-party не предупредив поменял контракт и парсинг упал, сервис не смог подняться и т.д). Оборачивать в try-catch удобнее чем checked exception, но использовать механизм для восстановления после сбоя ради трекинга ошибки между слоями - костыль и оверинжиниринг. Ошибки бизнес логики, доменной модели моделировать на исключениях вредно. В Java появился Optional, как первый шаг в понимании этой проблемы. Exceptions ради exceptions - это код ради кода, который увы пропагандируется мэтром Робертом Мартином.

[@Das.Kleine.Krokodil]

посоветуйте материалы по исключениям

[@feoktant]

@@Das.Kleine.Krokodil попробуйте написать самостоятельно такие правила) могу посоветоватьткнигуч но она на Скале

[@ИнякинАлександр]

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

[@glebkolobov]

Это кроме Раста ещё где-то есть?

[@feoktant]

​@@glebkolobov Optional в джаве уже есть лет 7. В Scala - Option, Either. Kotlin свободно дает реализовать Either. Часто в библиотеках вижу самописный аналог Either.

[@anatoliyshapovalov6791]

Футболка улётная, захотел такую

[@DimaVort]

Помню эти бесконечные try-catch нереально бесили в джава на андроид. Я хочу найти поле класса по имени, что там может сломаться? Нет же, вызывай через попытку.

[@PsychoDelissemo]

Люди забывают, что исключения - про исключительные ситуации, начинают управлять потоком выполнения программы через исключения

[@ДаниилГончаренко-г8я]

Фух, слава богу он "всё ещё...")))

[@ill_threads1628]

Сергей, когда Swift курс?

[@maxkiner4059]

Только сегодня наткнулся на коды возврата :D

[@SergeyNemchinskiy]

надо же!

[@maxlich9139]

и испытал то чувство, когда наткнулся в коде на коды возврата, а потом посмотрел видео Сергея про то, что это зло, и так делать не надо

[@PuHLiY92]

Спасибо

[@rymper]

Касательно перегрузки . Как быть если продукт использует ООП стиль в реализации на языке python ')

[@AlexKato-y7k]

не хватает картинок с примерами. "трай кетч, не бросайте. а делайте троу..." - ну как без примера, то? Псевдокод подойдет

[@АсенькаАлей]

Как считаете, если сейчас из айти сферы меня берут только в 1С😬 а мне бы хотелось скорее в разработку игр и приложений. Стоит ли идти куда берут, или работать на старой работе (не в сфере) и прокачивать в свободное время навыки, пока не возьмут куда хочется?

[@igorgrischenko6518]

Я вообще не работал пока меня не взяли на интересную работу разработки игр и приложений. Всё своё время тратил на изучение и делал свои проекты.

[@АсенькаАлей]

@@igorgrischenko6518 блин, а может и правда уволиться нафиг, и сидеть учиться спокойно🤔

[@igorgrischenko6518]

@@АсенькаАлей найдёшь работу, которая тебе нравится и не проработаешь ни дня)

[@liamsmith7052]

Сложный вопрос. Я перешёл в Asp.Net из 1С, давалось долго и с трудом. Все вечера и выходные уходили на освоение, и так полгода. В 1С вы точно научитесь поддерживать приложения с крупной кодовой базой и работать с большими запросами. Архитектура написана уже за вас и весьма продуманно, вам только писать функционал поверх. С другой стороны в 1С нет гита, вместо Кафок и RabbitMQ свой механизм обмена и вообще на всё свои эксклюзивные костыли. Всё это потом больно и долго придётся доучивать. Если речь идёт о разработке игр, скорее всего это язык со строгой типизацией, после 1С, Питона и ПХП тоже сразу не дастся, надо научиться мыслить типами и ООП. Если платить будут не меньше, и свободное время освоение 1С не будет отбирать у вакансии, куда вы хотите, то, на мой взгляд, стоит идти. Но 1С это тоже немаленький пласт такой, это маловероятно. Если 1С будет отбирать свободное время на доосвоение, то тут сложнее.

[@vyacheslavgvorus3883]

@@liamsmith7052 Бухгалтера у него время будут отбирать. Да и цифры гонять такое себе удовольствие. Пускай на фрилансе пилит мелкие заказы и практикуется.

[@pavelk2667]

Чудесно!

[@maximgc]

А как же Golang? Насчёт возврата ошибки

[@linkernick5379]

А как же Rust, возврат ошибки, с проверкой компилятором, но без бойлерплейта?

[@denislopatkin6996]

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

[@rudolfsikorsky7900]

Я, конечно, понимаю что прошло уже два года, но на случай если данные ролики будут рефакториться :) , хотелось бы чтобы текст сопровождался каким-то иллюстративным материалом: картинки, примеры кода. Я, например, не очень въехал как предлагается строить иерархию исключений, при этом делая их непроверяемыми. Я сейчас делаю так: к примеру, ошибка БД - я делаю RuntimeException и в сообщении пишу: "Database error, Query: 'здесь запрос, который был', Error: 'Record with ID 123 not found'". Далее оно улетает наверх и отображается в 500 ошибке сервера (сам сервер продолжает работать ессно). У меня внутренний энтерпрайз, поэтому я не боюсь запалить конкретный запрос в БД. Подозреваю что я что-то делаю неправильно, но как именно делать правильно - не понял. Оборачивать одно исключение в другое - понял. Как мне это поможет - не понял. Хотелось бы картинку :) Ну и обработка ошибок в реактивном стэке (Spring WebFlux) это отдельная песня - ничего непонятно, но очень интересно и инфы очень мало. Если будет такая возможность - хотелось бы послушать.

[@tadeuskozlovski7286]

👍

[@NameUnderscoreSurname]

Так я и не понял, что же по мнению Сергея нужно делать с checked exceptions. Если я должен отказаться от checked exceptions, приводите хотя бы пример какой-то, как я должен себя вести в ситуации когда нужно использовать условный FileInputStream. Мне наверх послать обработку ошибки или что?

[@artemboiarshinov]

Нужно поймать IOException в том методе, где используется код стандартной библиотеки, с помощью блока try catch -> обернуть в свое исключение, унаследованное от RuntimeException -> выбросить свое исключение

[@SergeyNemchinskiy]

@@artemboiarshinov спасибо, все верно

[@NameUnderscoreSurname]

@@artemboiarshinov спасибо за пояснение. В видео говорится о том, что блоки try catch засоряют код. А если этих стандартных библиотек использующих checked exceptions навалом в коде? Как вообще избежать использования checked exceptions если нужно работать с какими-нибудь стандартными библиотеками?

[@SilverBlade001]

Куча срача в комментариях: 🙃 >Не освещены время и место отлавливания и обработки 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 исключения сами по себе, или без них просто спокойнее тем, кто ранее привык к другим языкам, где их нет, это глубоко философский вопрос, в котором без поллитры не разобраться. 😁

[@woodzimierz9621]

Как правильно делать Error Handling по Klingon

[@marchenkoalexandr]

А может кто то плиз пояснить за checked vs unchecked exceptions? Я вот с Java на вы общаюсь, мне очень нравиться когда я пишу someLibrary.someMethod() IDE меня предупреждает о том что этот метод может вызвать исключения A, B, C и предлагает завернуть в try catch или «прокинуть» их дальше. Если же я такой же код пищу в C# я вообще без понятия что там может пойти не так. Когда говорится «не используйте checked exception” что собственно говоря подразумевается?

[@madcalm2024]

Огромное спасибо джаве что она не позволяет не заметить исключения )) Сколько раз это выручало ))

[@dmeheda]

А если я в методе (C#) специально делаю throw new Exception, а потом на верхнем уровне ловлю его. То это норм, или не стоит явно кидать исключение?

[@ex_death_x]

Если exception бросается при внештатной ситуации - норм, если это часть логики - антипаттерн (Control Flow Exceptions)

[@dmeheda]

@@ex_death_x спасибо

[@ekaterinaglushko6134]

15:10 - А как же аннотация @Nullable?

[@SergeyNemchinskiy]

а что она решает? Фактически это просто макияж для той же кучи обвязки

[@serikuser]

Throwable это насколько я помню, не интерфейс а родительский класс

[@kovalyurii7278]

Мені подобається підхід з Golang , коли функція повертає два значення - result, error

[@igorgrischenko6518]

Ну, я использую код возврата после того, как пришел ответ с сервера. Если он пришел с ошибкой - я возвращаю не объект, а строку "failed" и делаю проверку, если пришел "failed" то создать окно "что-то пошло не так" в самом приложении. Как мне эксепшен поможет окно создать?

[@0imax]

Эксепшен поможет прокинуть ошибку напрямую от места возникновения проблемы до места решения этой проблемы, минуя промежуточные вызовы. Например, вместо возврата строки "failed" и проверки её там наверху, можно просто бросить эксепшн, наверху в try блоке написать весь код так, будто всё прошло хорошо, а в catch блоке ловить все ошибки и выводить соответствующие окна. Таким образом код нормального поведения программы отделяется от обработки ошибок, не захламляется ими. Плюс, если какая-то ошибка произошла, а обработчика нет - это не останется незамеченным.

[@igorgrischenko6518]

@@0imax а, ты хочешь, чтобы я вместо возврата "failed" обернул код в try..catch и в ответе кидал эксепшен? Нуок, попробую

[@SergeyNemchinskiy]

@@0imax спасибо, отличный вариант

[@ntvisigoth]

"Меня все еще зовут Сергей Немчинский". Все услышу другое и сразу брошу исключение )

[@ill_threads1628]

NonStillSergeyNemchinskiyException

[@ExeyPanteleev]

Читаю на тизере NO CLEAN CODE

[@juliusmalkov9620]

И тут я понял, что у меня не так в пет проектах)

[@madcalm2024]

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

[@ИапГоревич]

Извините, но в последнее время я все больше изучаю OOA/OOD/OOP и наткнулся на две модели организации: богатая модель и анемичная. Считается, что анемичная модель плохая, поскольку "это не настоящий ООП". Не знаю насколько эта тема актуальна, вдруг Вы знаете ответ

[@zatraun]

Записывайтесь на курс Enterprise patterns, сможете вдоволь наговориться на эту тему) Если коротко: анемичная модель содержит недостатки, но по факту более распространена, т.к. фреймворки заточены именно под нее

[@ИапГоревич]

@@zatraun Спасибо большое! Я школьник, так что вряд ли мне деньги на это родители дадут

[@ИапГоревич]

@@zatraun Просто меня настораживает фраза "ненастоящее ООП". А так, вроде бы, удобно: класс данных и классы обслуживания. Единственный минус в этом только то, что высокая связанность. (Извините, могу плохо разбираться - сам все это изучаю только неделю)

[@zatraun]

​@@ИапГоревич ого, многие годами программируют и не задумываются о подобных вещах) Да, это удобно, поэтому так и распространено. Вся загвоздка в классах обслуживания - это по факту процедурный код, который сложно поддерживать и модифицировать. Чтобы решить эту проблему индустрия пошла не в сторону богатой доменной модели, а в сторону микросервисной архитектуры - на самом высоком уровне разбить приложение на небольшие куски, которые будут достаточно просты, чтобы анемичная доменная модель с ними справилась.

[@ИапГоревич]

@@zatraun Спасибо Вам за тему! Я всю неделю принципы SOLID учил :D

[@liubomyr-peteliuk]

Слушаю про null и получаю флешбеки по вордпресу где вызывают функцию и туда три параметра с null закидуют :)

[@vyacheslavgvorus3883]

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

[@liubomyr-peteliuk]

@@vyacheslavgvorus3883 А где я писал, что вордпрес это библиотека? К чему это? Или вы ответ не тому комменту дали?

[@vyacheslavgvorus3883]

@@liubomyr-peteliuk Удивился удивлению. Не хотел задеть вашу самооценку.

[@liubomyr-peteliuk]

@@vyacheslavgvorus3883 ахах, нечего не понял))

[@glebbondarenko67]

Начинаю срач: 1. начнем с того, что промышленного кода на C# меньше чем на той же Java с этими "ненавистными" check exceptions 2. в JavaScript вообще нету exception. "Ну и парни как то работают" - такой себе аргумент 3. А теперь по делу в Kotlin как и в C# все exceptions - unchecked - всё было хорошо, код бросал exception, на верхнем уровне ловил, обрабатывал особым образом, тестами всё покрыто - конфетка - происходит рефакторинг - и метод больше не бросает этот exception в результате, т.к. проверки на уровне компилятора нет - то остался "специальный обработчик" а это значит что остался код который НИКОГДА не выполнится остались тесты для этого кода а мы знаем по предыдущем видео от Сергея, что кол-во багов на кол-во строк кода - константа и не важно выполняется этот код или нет

[@0imax]

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

[@bubblesort6368]

В js есть исключения и их также можно ловить в try/catch. С ними есть некоторые особенности, но они есть и используются)

[@glebbondarenko67]

@@bubblesort6368 во блин. Как все поменялось :))))

[@bogdanplishchenko5423]

касательно checked exceptions и того почему их не используют. Java не задизайнена для высоконадежных систем, в том числе и хибернейт и много библиотек, поэтому в мире жавы принято кидать рантаймы. Если же всеже приходиться писать чтото надежное то рантайм ексепшины это боль (приблизительно как и динамическая типизация). Странно слышать такую катигоричную точку зрения от вроди как опытного дева.

[@revetastogne]

Помнится, в новых версиях Java улучшили NPE - он теперь показывает какой именно обьект в цепочке оказался null

[@SergeyNemchinskiy]

все верно. нов се равно лучше делать так, как я написал

[@ВадимЛяпин-м5п]

"Никаких кодов возврата в ООП языке". А как насчёт взаимодействия ООП кода с процедурным (например, вызов процедуры из БД)? Холивар по этой теме знатный, но как насчёт КлинКода? "Никогда не возвращайте null". И что делать в случае, когда возвращается null из БД? Это ведь вполне допустимое состояние для реляционных БД.

[@woodzimierz9621]

Как вариант воспользоваться паттерном ValueObject

[@feoktant]

> А как насчёт взаимодействия ООП кода с процедурным В библиотеке Skunk для работы с Postgres все ошибки последнего были записаные в sealed trait. Нечто подобное можно получить написав Enum на джаве, и использовать самописный Either. В КлинКод ответа не будет, потому что Роберт Мартин любит безтиповые языки, и считает что на всё нужно писать юнит тест. > И что делать в случае, когда возвращается null из БД? Либо Optional либо создать свой DbNull и писать логику согласно ему. Если пишите за деньги, то скорее всего будете использовать фреймворк, и он сам диктует как работать c null.

[@NikitaZenkin]

Непонятно для golang разработчика) какие экспшены...

[@SergeyNemchinskiy]

для других программистов - а что Go - это язык? %)

[@DVBLEX]

{{'Error! ' + errorMsg}} - у меня вот такой лог в приложении, кто вкурсе что он значит ?

[@max_mgtow]

Писано индусом 😆

[@igorgrischenko6518]

О, я же такое же писал три дня назад.