Всем привет!

Проверяемые исключения - еще одна вещь, которой отличаются 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://www.youtube.com/watch?v=UIbbNsta2UE

Краткий конспект, не влияющий на рекомендацию посмотреть видео:
1) затраты на выбрасывание исключений конечно же есть, но если исключение в вашем сервисе равно ошибке, то проблем с производительностью не будет. Т.к. ошибки как правило не выбрасываются сотнями и тысячами в секунду
2) если ваши исключение выбрасывается в строго определенном месте кода - можно убрать из него stack trace, это неплохо так увеличит производительность. На самом деле если просто не обращаться к stack trace, то она уже увеличится, но для надежности лучше вообще не прикреплять stack trace к исключению. Или использовать StackWalking API https://www.baeldung.com/java-9-stackwalking-api
3) самый спорный и опасный совет для того же кейса - исключение, выбрасываемое в одном месте - закэшировать исключение, так его выброс будет еще быстрее. Но по сути это старый добрый go to. Использовать с осторожностью!)
4) исключение должно содержать весь контекст ошибки, в идеале с предложениями по ее исправлению. Чтобы структурировать информацию об ошибке есть библиотека https://github.com/melix/jdoctor Активность в репозитории слабенькая, но сама идея мне нравится.
5) как известно, есть исключения, которые не стоит ловить - например, OutOfMemory и StackOverflow. Но если очень надо, то OutOfMemory все же можно) Главное - заранее создать все необходимые для сохранения информации о проблеме объекты, ведь после появления OutOfMemory памяти уже не будет.

А еще из интересного - после просмотра видео станет понятно, как работает SneakyThrows в Lombok

#java #exceptions