Комментарии 5
Не используйте исключения, если не хотите, чтобы исполнение кода не закончилось совсем. Если используете try/catch, вы добавляете неявное значение, возвращаемое из функции. По сути сигнатура становится не то, что бессмысленной, но не описанной до конца. Есть масса вариантов возвращения: Option/Optional, Result/Try, Either. Думайте в разных парадигмах, а не только в ООП. ООП дивно хороша, но текущие реализации далеки от идеала. Мощь ООП хорошо раскрывается в комбинации с ФП.
А есть примеры best practice? Может ссылка на статью?
мне очень нравится вариант, который используется в Golang'е, т.е. value, err := someFunc(); дальше проверяем если err != nil то что-то делаем.
но для того же PHP например приходится либо в массиве это возвращать return [$result, $err];
и потом проверять if ($result[1] != null) {...} либо в класс какой то оборачивать, можно ассоциативным массивом, самый простой вариант. Но по сути это просто делаем одно и тоже разными способами. Кому то нравится так, кому то так. Нет ничего в этой жизни не правильного, все правильное и так и эдак!
Ну чтобы она была описана до конца надо просто добавить исключения в сигнатуру метода. И я не говорю про NPE и различные технические рантайм исключения, а именно про исключения бизнес логики. Просто на возвращаемый тип и объявленные исключения метода стоит смотреть на один тип данных, в случае вызова метода вернётся или то или другое.
Можно конечно возвращать Try или Either, но проблема в том что бросив на него взгляд не всегда понятно что именно может вернуть метод. Результат или исключение это очень широкие границы. В отличие от конкретного декларирования исключений.
Да будет ХолиВар!
1) Книга относится к ООП, и рекомендации тоже.
2) >> Не используйте исключения, если не хотите, чтобы исполнение кода не закончилось совсем
В тех примерах которые были приведены, это будет хорошей практикой для императивного кода ООП (когда исключение словится где-то наверху и просто залогируется, а запрос/транзакция сама отменится/зафейлится)
3) >> Option/Optional, Result/Try, Either
Эти ФП подходы хороши в случае организации кода в виде цепочек. Использование их для классического императивного кода только усложняет код, особенно если базовые библиотеки кидают исключения. В случае Java: streams (как часть ФП) нормально перепрокинут их наверх, а React frameworks (RxJava, so on) нормально обернут Exceptions в реактивные аналоги Try (с реактами иногда проще использовать их Try сразу без Exception, но это уже по ситуации)
4) >> Мощь ООП хорошо раскрывается в комбинации с ФП.
В тех местах где язык/framework это предполагает/допускает (иначе имеем спагети-код с дикой смесью различных подходов)
Хочется ФП - используйте ФП язык (иначе имеем что-то типа Scala - у нас тут и ФП, и ООП, но ты ("туда не ходи") ООП не юзай, а то по рукам получишь :-) )
Книга «Объекты. Стильное ООП»