Ну вот рекомендации в новомодных языках: https://docs.flutter.dev/app-architecture/design-patterns/result

— все-таки топят за Result objects для бизнес-логики.

А ведь это всю цепочку поддерживать. Как-то много лишних букв добавляется.

Но! Exception как бы не определены в контрактах. Если ResultObject — это контракт, его понятно что нужно проверить и компилятор даже контролирует эту проверку. А Exception разве что в документации описан, которую могут не читать.

А ведь было же хорошее решение — т.н. проверяемые исключения в Java. Когда компилятор требовал проверки того или иного исключения, но так же была возможно обернуть в RuntimeException, если оно утратило смысл бизнес-логики или ожидаемого

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

Ну вот рекомендации в новомодных языках: https://docs.flutter.dev/app-architecture/design-patterns/result

— все-таки топят за Result objects для бизнес-логики.

А ведь это всю цепочку поддерживать. Как-то много лишних букв добавляется.

Но! Exception как бы не определены в контрактах. Если ResultObject — это контракт, его понятно что нужно проверить и компилятор даже контролирует эту проверку. А Exception разве что в документации описан, которую могут не читать.

А ведь было же хорошее решение — т.н. проверяемые исключения в Java. Когда компилятор требовал проверки того или иного исключения, но так же была возможно обернуть в RuntimeException, если оно утратило смысл бизнес-логики или ожидаемого

Но, как оказалось, народ идеи не понял. Так и вернулись к понятным дебилоидам кодам возврата, т.к. проверяемые исключения осилить не смогли. Так же и в Kotlin их решили не делать.