на список результатов и то что знаешь какие исключения обрабатывать тут не надо. Так?
Сам по себе ExceptT — очень полезный трансформер. Всё зависит от того, в каком контексте использовать ExceptT. Если вместе с IO, то есть различные проблемы (какие-то из них уже упомянули в треде выше). Но в контексте чистых вычислений (например вместе с монадами Reader или State) очень удобно, так как позволяет создавать более удобные интерфейсы. Я даже блог пост писал с одним примером использования ExceptT + State https://kowainik.github.io/posts/2018-11-18-state-pattern-matching Проблемы ExceptT + IO: 1. Два источника ошибок, нужно в двух местах ловить. 2. Поведение ExceptT можно проэмулировать через IO при желании. Это даже будет более эффективно, так как добавление ExceptT приносит некоторый оверхед: на каждом >>= будет паттерн мэтчинг по Either (просто из-за того, как работает ExceptT). Я бенчмарки не писал, не видел, насколько будет медленней (в реальной жизни это точно не основная проблема), но всё же. 3. Если в трансформере монад есть ExcepT, то некоторые инстансы нельзя написать. Например, сейчас в экосистеме Haskell очень популярный модный подход с ReaderT IO и абстракциями вроде MonadUnliftIO. Если в трансформере появляется ExceptT, то эти инстансы уже не написать и не самой плохой частью экосистемы пользоваться не получится.
Обсуждают сегодня