wat.txt

scala> run(F.raiseError[String](42).map(_.asRight[Int]).handleErrorWith(_.asLeft[String].pure[PureConc[Int, ?]]))
res11: ce3.ExitCase[Option,Int,Either[Int,String]] = Completed(Some(Left(42)))

scala> run(F.attempt(F.raiseError[String](42)))
res12: ce3.ExitCase[Option,Int,Either[Int,String]] = Errored(42)

Hey, I ran into a similar issue today.

Effect definition:

import cats.data.EitherT
import cats.effect.IO
import cats.syntax.applicativeError._

type F[A] = EitherT[IO, String, A]

val error = new RuntimeException("my error")
val io = IO.raiseError[Either[String, Int]](error)
val fa: F[A] = EitherT(io)

Example #1:

println(fa.attempt.value.unsafeRunSync())

// Throws exception: java.lang.RuntimeException: my error

The compiler chooses EitherT.catsDataMonadErrorForEitherT as MonadError instance and evaluation fails.

Example #2:

println(ApplicativeError[F, Throwable].attempt(fa).value.unsafeRunSync())

// Output: Right(Left(java.lang.RuntimeException: my error))

In this case, the compiler chooses EitherT.catsDataMonadErrorFForEitherT and everything works fine.

The catsDataMonadErrorForEitherT has higher priority then catsDataMonadErrorFForEitherT until the error type is not provided explicitly.

Wow! That is absolutely fascinating and concerning.