Custom Error Types Using Cats Effect and MTL

"One of the most famous and longstanding limitations of the Cats Effect IO type (and the Cats generic typeclasses) is the fact that the only available error channel is Throwable. This stands in contrast to bifunctor or polyfunctor techniques, which add a typed error channel within the monad itself. You can see this easily in type signatures: IO[String] indicates an IO which returns a String or may produce a Throwable error ( Future[String] is directly analogous)."

"In a meaningful sense, this type of bifunctor error encoding is analogous to checked exceptions in Java, whereas monofunctor error encoding (like Cats Effect's IO) is analogous to unchecked exceptions. Both are valid design decisions for an effect type, but they come with different benefits and tradeoffs. Cats has long been quite prescriptive about monofunctor effects, in part because this considerably simplifies the compositional integration space."

Cats Effect IO and the Cats typeclasses expose only a Throwable error channel, unlike bifunctor or polyfunctor encodings that allow typed error channels inside the monad. Bifunctor encodings such as BIO[Error, A] permit user-specified error types and are more explicit about where errors may occur. This difference resembles checked versus unchecked exceptions and leads to different tradeoffs. The Cats ecosystem has preferred monofunctor effects to simplify compositional integration, concurrency, and resource handling, helping libraries rely on a consistent F[_] model. Cats MTL 1.6.0 introduces a lightweight syntax to manage user-defined error types without heavy transformer machinery.

Read at Typelevel