Всем привет!
Проверяемые исключения - еще одна вещь, которой отличаются Java и Kotlin.
В Kotlin их нет, и вот тут описано почему https://kotlinlang.ru/docs/reference/exceptions.html
Там же есть ссылка на диалог таких известных людей как Bruce Eckel и Anders Hejlsberg на эту тему https://www.artima.com/articles/the-trouble-with-checked-exceptions
Вот тут есть его русский перевод https://habr.com/ru/articles/221723/
В целом соглашусь с основным аргументом авторов: с ростом кодовой базы - а тут важно помнить, что кроме кода сервиса мы еще используем кучу библиотек включая вездесущий Spring Framework - проверяемых исключений становится слишком много. А их выборочная обработка в бизнес приложении, которое активно использует внешние библиотеки, часто не нужна. Т.е. есть цепочка вызова из к примеру 10 сервисов, а обработка исключений - в одном из них, максимум в двух. В остальных случаях их приходится пробрасывать. Отсюда приходим к throws Exception. А это явный антипаттерн.
Следовательно, в большинстве случаев вред от проверяемых исключений перевешивает пользу. Хотя идея - если рассматривать ее именно как идею - красивая: объявляем в API не только типы входящих и исходящих параметров, но и потенциально возможные ошибки. Вот только удобной реализации пока никто не придумал)))
#java #kotlin #exceptions #checked_exceptions
Проверяемые исключения - еще одна вещь, которой отличаются Java и Kotlin.
В Kotlin их нет, и вот тут описано почему https://kotlinlang.ru/docs/reference/exceptions.html
Там же есть ссылка на диалог таких известных людей как Bruce Eckel и Anders Hejlsberg на эту тему https://www.artima.com/articles/the-trouble-with-checked-exceptions
Вот тут есть его русский перевод https://habr.com/ru/articles/221723/
В целом соглашусь с основным аргументом авторов: с ростом кодовой базы - а тут важно помнить, что кроме кода сервиса мы еще используем кучу библиотек включая вездесущий Spring Framework - проверяемых исключений становится слишком много. А их выборочная обработка в бизнес приложении, которое активно использует внешние библиотеки, часто не нужна. Т.е. есть цепочка вызова из к примеру 10 сервисов, а обработка исключений - в одном из них, максимум в двух. В остальных случаях их приходится пробрасывать. Отсюда приходим к throws Exception. А это явный антипаттерн.
Следовательно, в большинстве случаев вред от проверяемых исключений перевешивает пользу. Хотя идея - если рассматривать ее именно как идею - красивая: объявляем в API не только типы входящих и исходящих параметров, но и потенциально возможные ошибки. Вот только удобной реализации пока никто не придумал)))
#java #kotlin #exceptions #checked_exceptions
Всем привет!
Недавно я хвалил Java, пришло время поругать) Для начала вот фактура:
https://habr.com/ru/articles/676852/
Если вкратце: в Java есть стримы и есть проверяемые исключения. Если первые совместить со вторыми - код стримов из компактного и красивого становится ужасным. Да, технически все работает, но теряется смысл стримов - компактный код в функциональном стиле.
С одной стороны можно сказать - да и фиг с ними, с этими проверяемыми исключениями. Да, их можно не использовать в своем коде. Я, например, так и делаю, т.к. недостатки проверяемых исключений перевешивают их преимущества, см. https://t.me/javaKotlinDevOps/205.
Но во-первых они могут приходить к нам из внешних библиотек, а во-вторых основной принцип Java, ее сила - максимальная совместимость. Именно совместимостью оправдывается скорость развития Java. А тут получается про нее забыли. И что важно - streams появились в Java 8. Недавно вышла Java 21. Функционал проверяемых исключений хоть особо не развивается, но и не стал deprecated. Значит условный Try из статьи выше должен быть в стандартной библиотеке Java.
#java #exceptions #checked_exceptions #java_streams
Недавно я хвалил Java, пришло время поругать) Для начала вот фактура:
https://habr.com/ru/articles/676852/
Если вкратце: в Java есть стримы и есть проверяемые исключения. Если первые совместить со вторыми - код стримов из компактного и красивого становится ужасным. Да, технически все работает, но теряется смысл стримов - компактный код в функциональном стиле.
С одной стороны можно сказать - да и фиг с ними, с этими проверяемыми исключениями. Да, их можно не использовать в своем коде. Я, например, так и делаю, т.к. недостатки проверяемых исключений перевешивают их преимущества, см. https://t.me/javaKotlinDevOps/205.
Но во-первых они могут приходить к нам из внешних библиотек, а во-вторых основной принцип Java, ее сила - максимальная совместимость. Именно совместимостью оправдывается скорость развития Java. А тут получается про нее забыли. И что важно - streams появились в Java 8. Недавно вышла Java 21. Функционал проверяемых исключений хоть особо не развивается, но и не стал deprecated. Значит условный Try из статьи выше должен быть в стандартной библиотеке Java.
#java #exceptions #checked_exceptions #java_streams
Хабр
Обработка исключений в Java в функциональном стиле
Обработка исключений в Java в функциональном стиле В данной статье автор предоставит информацию о собственной библиотеке для обработки исключений (Exception) в функциональном стиле. Предпосылки В Java...