👨‍💻 После Senior ВСЕ? Как программисту развиваться после Senior и куда двигаться в айти? 👉 kzfaq.info/get/bejne/hNR9ZLKVlrqvlHU.html

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

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

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

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

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

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

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

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

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

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

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

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

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

Чудесно!

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

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

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

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

Спасибо

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

👍

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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