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 generic Cats typeclasses expose only Throwable as the error channel, preventing user-specified error types inside effect types. Bifunctor or polyfunctor encodings add a typed error channel to the monad, enabling signatures like BIO[ParseError, String] that explicitly carry domain errors. Bifunctor error encoding is analogous to checked exceptions, while monofunctor encoding resembles unchecked exceptions, each with tradeoffs. Cats favors monofunctor effects because that simplifies compositional integration, yielding consistent behavior across libraries and allowing simpler concurrent and resource-handling implementations. The need for custom error types remains important in domains like parsing.

Read at Typelevel