🚧🛠

Закрыто на технические работы попробуйте через 24 часа

вот где выдавали гем, туда и обращайтесь

подход результирующих объектов клевый и мы его используем в проекте, но у меня всегда возникали вопросы как его правильно готовить)
в таком подходе есть след проблема: все разрабочитки используют очень много стороннего кода, в котором невозможно контролировать использование эксепшенов.
и я вижу только три варианта, которые все мне не нравятся: либо не отлавливать, что мы не можем обработать, и тогда у нас получается какое-то двоевластие, либо не использовать сторонний код, использующий исключения, что кажется невозможным, либо обрабатывать все исключения при каждом вызове стороннего кода, что несет в себе бойлерплейт.
также непонятно как правильно в последнем варианте логировать или отображать разработчику ошибки, которые мы не можем обработать.
кажется логичным обрабатывать такие в единой точке в базовом контроллере и джобе, но нам нужна информация где была поймана эта ошибка, значит нужно либо передавать в Failure уникальные значения, обозначающие ошибки, что кажется невыполнимым, либо передавать бэктрейс в Failure, что добавит еще бойлерплейт и кажется переизобретением эксепшенов, либо в Failure передавать эксепшен, что не кажется идиоматическим.

> все разрабочитки используют очень много стороннего кода, в котором невозможно контролировать использование эксепшенов

а расскажи про примеры, пожалуйста

про трейс ошибок - никита же сделал все уже
https://dry-rb.org/gems/dry-monads/1.3/tracing-failures/

первую часть не смог понять, можно пояснить?

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

отлавливать нужно ИСКЛЮЧИТЕЛЬНО то, что умеем обрабатывать

у нас проект построен на экспшенах, очень удобно, для них сделаны отдельные классы и можно всегда отловить отдельный бизнес кейс (где экспешен это не обязательно ошибка, а просто реакция, в место какого-то стейта\флага) для таких ексепшенов есть отдельный обработчик, все остальное обрабатывается стандартным

А я только собрался начать миграцию с dry-transaction в dry-монады и do notation.
А может это шанс вернуться к истокам? к исключениям? )

к лонг джампам

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

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

все классы унаследаны от BaseAppError, а под нужные случае создается отдельный класс, с своим кодом. К примеру та же валидация, построена на ексепшенах

((пошел включать песню road to hell))

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

не знал, спасибо))

Мне кажется, если основная претензия к исключениям, это запутанность кода (непонятно, где обрабатывается),
то если нет "глобального" обработчика, а они обрабатываются сразу на выходе из "бизнес"-слоя, то разницы с result-объектами не очень много.

Но если логика будет усложняться, то комбинировать разные "сервисы"/"операции"/"команды" будет уже труднее.

В расте нет исключений(т.е. есть конечно, но их не надо обрабатывать, они как раз на случай когда надо упасть), а с ошибками они наоборот проебались изначально

Глобальные обработчики всего (включая сторонние библиотеки) это худшее, что можно придумать. Такой подход может приводить к тому, что состояние программы станет неконсистентным, нормальное выполнение невозможным, но все как-то будет держаться на плаву, потому что программе упасть не дали.