Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add bridge between ApplicativeError and ApplicativeThrow #4616

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open

Add bridge between ApplicativeError and ApplicativeThrow #4616

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
8408933
Add bridge between ApplicativeError and ApplicativeThrow
morgen-peschke Jun 10, 2024
366d776
Tighten mapping requirements of catchOnlyAs
morgen-peschke Jun 11, 2024
e29d1d6
Add catch*Unsafe variants
morgen-peschke Jun 13, 2024
945dfd9
Merge branch 'typelevel:main' into add-bridge-from-throwable-to-error
morgen-peschke Jul 12, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 35 additions & 1 deletion core/src/main/scala/cats/ApplicativeError.scala
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -21,7 +21,7 @@

package cats

import cats.ApplicativeError.CatchOnlyPartiallyApplied
import cats.ApplicativeError.{CatchOnlyAsPartiallyApplied, CatchOnlyPartiallyApplied}
import cats.data.{EitherT, Validated}
import cats.data.Validated.{Invalid, Valid}

Expand Down Expand Up @@ -287,6 +287,30 @@ trait ApplicativeError[F[_], E] extends Applicative[F] {
def catchOnly[T >: Null <: Throwable]: CatchOnlyPartiallyApplied[T, F, E] =
new CatchOnlyPartiallyApplied[T, F, E](this)

/**
* Often E can be created from Throwable. Here we try to call pure or
* catch, adapt into E, and raise.
*
* Exceptions that cannot be adapted to E will be propagated outside of `F`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Repeating my comments from #4286 (comment):

This doesn't seem right to me. Exception-throwing code should ideally never be written outside of a catchNonFatal; pure code that uses this method (or any method in Cats) should not throw exceptions.

It seems to me what you actually want is maybe something like F[G[A]], with ApplicativeError[G, E] and ApplicativeThrow[F]. That way non-adaptable exceptions can be safely handled in the F effect.

In which case I think you want something like this?

F.catchNonFatal(doTheThing()).map(G.pure).recover {
  case ex: MyAdaptableException => G.raiseError(whatever)
}

Maybe a dedicated method/syntax could make that a bit neater. I'm not entirely sure where it could live.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding the extra effect layer would make these incongruent with catchOnly, which also throws exceptions that aren't expected, rather than attempting to raise them in F.

If there were a less clunky way to do the .map(G.pure).recover { ... }, that would improve the ergonomics enough for the usecase to basically disappear into Sync[F].delay + whatever the improvement is.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Honestly, I personally have never used catchOnly before, and never paid attention to it. And now I'm a bit surprised that such a function even exists in here.

On the other hand though, there are several examples in Cats when a function can throw an exception, e.g. NonEmptyList.fromListUnsafe and alike. It is a slightly different case though, because happens not in a type class but rather in a particular data type. But still close.

From that point of view, if we want to have functions in Cats like catchOnly or similar that can (re)throw exceptions, then perhaps it makes sense to mark them "unsafe", because they really are, e.g.: unsafeCatchOnly or catchOnlyUnsafe. And also explain in the docs, why they are unsafe.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would the path forward then be to rename/deprecate the existing catch* methods?

Copy link
Contributor

@satorg satorg Jun 12, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this PR would be better off staying focused on its initial goal.
Perhaps, it makes sense to provide a safe version of catchNonFatalAs as @armanbilge suggested along with its unsafe counterpart.

The effort on renaming of the existing unsafe methods could be addressed in a separate PR later on. Actually, not all the existing catch* methods look unsafe to me, only catchOnly does. On the other hand, not only ApplicativeError contains catchOnly but also Validated and EitherSyntax have their specialized versions that can be considered unsafe in the same way. So the renaming is likely worth a separate PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I figured the easiest way to advance would be to implement *Unsafe versions of the proposed methods, and a catchOnlySafe version of catchOnly.

This way we have concrete implementations to look at and figure out which add value.

*/
def catchNonFatalAs[A](adaptIfPossible: Throwable => Option[E])(a: => A): F[A] =
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would probably prefer to deal with PartialFunction in such a case. Not only it allows to avoid an extra allocation, but also simpler to write a handler, e.g:

def catchNonFatalAs[A](adaptIfPossible: PartialFunction[Throwable, E])...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not mentioning that the handler would look more like a regular catch in that case.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, using PFs for error handling is a common practice 👍🏻

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would expect most times adaptIfPossible will be a method reference, so it would look like this:

ApplicativeError[Either[E, *], E].catchNonFatalAs(E.fromThrowable) { 
  // block
}

I'm open to being wrong about this, I just expect this sort of transformation won't generally written at the call sites because, if you need to do this, you probably need to do it more than once.

try pure(a)
catch {
case e if NonFatal(e) => adaptIfPossible(e).map(raiseError[A]).getOrElse(throw e)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line concerns me quite a lot, particularly throw e.
It means that the exception will be re-thrown out of the F context, which is not what I would expect from any ApplicativeError instance.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unless we require the adaptation function to be total, we're going to need to rethrow these, because there isn't a way to raise a Throwable into an arbitrary ApplicativeError[F, E]

Copy link
Member

@armanbilge armanbilge Jun 11, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, exactly. This is why we must not use a PartialFunction as you suggested in #4616 (comment). See my comments in #4286 (comment).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@armanbilge , PartialFunction[A, B] and A => Option[B] are isomorphic. Do I understand correctly your point that we must not use either of them?

}

/**
* Evaluates the specified block, catching exceptions of the specified type and maps them to `E`.
*
* Uncaught exceptions will be propagated outside of `F`
*
* Note: `catchOnlyAs` assumes that, if a specific exception type `T` is expected, there
* exists a mapping from `T` to `E`. If this is not the case, consider either manually
* rethrowing inside the mapping function, or using `catchNonFatalAs`
*/
def catchOnlyAs[T >: Null <: Throwable]: CatchOnlyAsPartiallyApplied[T, F, E] =
morgen-peschke marked this conversation as resolved.
Show resolved Hide resolved
new CatchOnlyAsPartiallyApplied[T, F, E](this)

/**
* If the error type is Throwable, we can convert from a scala.util.Try
*/
Expand Down Expand Up @@ -383,6 +407,16 @@ object ApplicativeError {
}
}

final private[cats] class CatchOnlyAsPartiallyApplied[T >: Null <: Throwable, F[_], E](
private val F: ApplicativeError[F, E]
) extends AnyVal {
def apply[A](adapt: T => E)(f: => A)(implicit CT: ClassTag[T], NT: NotNull[T]): F[A] =
try F.pure(f)
catch {
case CT(t) => F.raiseError(adapt(t))
}
}

/**
* lift from scala.Option[A] to a F[A]
*
Expand Down
26 changes: 26 additions & 0 deletions tests/shared/src/test/scala/cats/tests/EitherSuite.scala
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -23,6 +23,7 @@ package cats.tests

import cats._
import cats.data.{EitherT, NonEmptyChain, NonEmptyList, NonEmptySet, NonEmptyVector, Validated}
import cats.syntax.option._
import cats.syntax.bifunctor._
import cats.kernel.laws.discipline.{EqTests, MonoidTests, OrderTests, PartialOrderTests, SemigroupTests}
import cats.laws.discipline._
Expand Down Expand Up @@ -136,6 +137,31 @@ class EitherSuite extends CatsSuite {
assert(Either.catchNonFatal(throw new Throwable("blargh")).isLeft)
}

test("ApplicativeError instance catchNonFatalAs maps exceptions to E") {
val res = ApplicativeError[Either[String, *], String].catchNonFatalAs(_.getMessage.some)("foo".toInt)
assert(res === Left("For input string: \"foo\""))
}

test("ApplicativeError instance catchNonFatalAs propagates unmappable exceptions") {
val _ = intercept[NumberFormatException] {
ApplicativeError[Either[String, *], String].catchNonFatalAs(_ => none[String])("foo".toInt)
}
}

test("ApplicativeError instance catchOnlyAs maps exceptions of the specified type to E") {
val res =
ApplicativeError[Either[String, *], String]
.catchOnlyAs[NumberFormatException](_.getMessage)("foo".toInt)
assert(res === Left("For input string: \"foo\""))
}

test("ApplicativeError instance catchOnlyAs propagates non-matching exceptions") {
val _ = intercept[NumberFormatException] {
ApplicativeError[Either[String, *], String]
.catchOnlyAs[IndexOutOfBoundsException](_.getMessage)("foo".toInt)
}
}

test("fromTry is left for failed Try") {
forAll { (t: Try[Int]) =>
assert(t.isFailure === (Either.fromTry(t).isLeft))
Expand Down
Loading