Implemented submarine error propagation for `Handle` #489

djspiewak · 2023-04-30T17:09:50Z

This adds builder syntax to Handle which makes it possible to materialize an instance of Handle for any error type given an ApplicativeThrow[F]. Syntax is intentionally reminiscent of try/catch:

def foo[F[_]](implicit h: Raise[F, DomainError]) = ???
def bar[F[_]](implicit h: Handle[F, DomainError]) = ???

Handle.ensure[IO, DomainError] { implicit h =>
  foo *> bar
} recover {
  case DomainError.Failed => ...l
  case DomainError.Derped => ...
}

You can see some other examples in the tests. You can suspend as many different error types as you want and it all composes the way you would expect.

This effectively eliminates the need for EitherT or IorT outside of tests (where both can still be useful for building ad-hoc harnesses that are less powerful than IO). Types infer quite nicely on both Scala 2 and Scala 3, though obviously Scala 3's using syntax makes this even nicer.

armanbilge

I'm somewhat meh about the names ensure and recover, sorry ... not that I have any better ideas 😛

So on ApplicativeError we have recover which takes a PartialFunction[E, A] and doesn't match how it is used here. handleErrorWith matches more closely the E => F[A].

Meanwhile on MonadError we have ensure with takes a predicate: A => Boolean.

armanbilge · 2023-04-30T20:55:25Z

tests/shared/src/test/scala/cats/mtl/tests/HandleTests.scala

+    assert(test.value.value.toOption == Some("third1"))
+  }
+
+  {


Should this be a test("...") { ?

Can it be? I have no idea how that works in MUnit.

I'm confused :) is this a test or not haha, that is really what I am asking 😂

It's a lexical block which contains Discipline stuff, which is many tests.

Oh I see now, sorry. I was confused by the end of the block, it looked like an ordinary test ... but it's because the discipline tests have to exist inside of the Eval since that's how the Handle is constructed. Thanks!

cats-mtl/tests/shared/src/test/scala/cats/mtl/tests/HandleTests.scala

Lines 122 to 124 in 0b8e897

test.value.value

()

}

tests/shared/src/test/scala/cats/mtl/tests/HandleTests.scala

armanbilge · 2023-04-30T20:57:12Z

core/src/main/scala/cats/mtl/Handle.scala

  def apply[F[_], E](implicit ev: Handle[F, E]): Handle[F, E] = ev
+
+  def ensure[F[_], E]: AdHocSyntax[F, E] =


Should we ask for the ApplicativeThrow constraint here, and then pass it into AdHocSyntax?

If we do, we lose the syntax and have to insert extra parens at the call site.

tests/shared/src/test/scala/cats/mtl/tests/HandleTests.scala

armanbilge · 2023-04-30T21:05:29Z

core/src/main/scala/cats/mtl/Handle.scala

+  }
+
+  private final case class Submarine[E](e: E, marker: AnyRef)
+      extends RuntimeException


Should this just extend Throwable? (Or even ControlThrowable, but I think that one is considered fatal by NonFatal.) It's not really an ordinary exception, and even if it leaked, without a stacktrace it would be hard to do something about it 😅

I went back and forth. Technically RuntimeException is accurate and appropriate, but it's all sort of dependent on perspective. Certainly anything that would be considered fatal is off the table since it just instantly torpedoes the whole runtime.

Co-authored-by: Arman Bilge <[email protected]>

djspiewak · 2023-05-01T00:37:57Z

Also meh about the names. That's actually the hardest part of this PR honestly. I was going for something close to try/catch, since the structure is precisely analogous. "Rescue" is another word I had in mind (Ruby's equivalent of try/catch is ensure/rescue), but it's not great either way. Attempt would be ideal but that's very much off the table.

benhutchison · 2023-05-01T02:35:49Z

Cool! Having previously built my own Submarine out of cardboard and duct tape to sail the "Sewers of IO", I welcome this factory-built model. Can I paint it yellow?

armanbilge · 2023-05-01T03:03:30Z

Ruby's equivalent of try/catch is ensure/rescue

Actually I think it's begin/rescue/ensure as in try/catch/finally. That seems like a more appropriate use of "ensure" 😜

So we could have Handle.begin { ... } rescue { ... } or maybe Handle.in { ... } rescue { ... }? I also entertained ideas of embed or embedError since we are embedding E in the outer effect 🤔

djspiewak · 2023-05-09T18:05:40Z

So we could have Handle.begin

Oh this is an interesting idea. It would allow us to potentially have uniform syntax across the classes.

armanbilge · 2023-05-09T18:44:15Z

more thoughts:

we should consider having a cross-compilable syntax for 2/3 as well as a Scala 3 only syntax which uses Context functions. Annoyingly the method name will need to be different.

Handle.begin[IO, DomainError] { // look ma, no implicit!
  foo *> bar
} rescue {
  case DomainError.Failed => ???
  case DomainError.Derped => ???
}

braceless syntax is increasing in popularity. will this work? if not then how does it look without braces?

Handle.begin[IO, DomainError]:
  foo *> bar
rescue:
  case DomainError.Failed => ???
  case DomainError.Derped => ???

can we make the type parameter for F[_] go away? it should be inferable from the body.

Handle.begin[DomainError]:
  foo *> bar
rescue:
  case DomainError.Failed => ???
  case DomainError.Derped => ???

armanbilge · 2023-05-11T03:43:24Z

core/src/main/scala/cats/mtl/Handle.scala

+
+  final class AdHocSyntax[F[_], E] {
+
+    def apply[A](body: Handle[F, E] => F[A])(implicit F: ApplicativeThrow[F]): Inner[A] =


Could we implement this with Handle[F, Throwable] instead of ApplicativeThrow[F]?

armanbilge · 2023-05-11T05:02:21Z

Cool, I prototyped the syntax for Scala 3 and was able to make this work:

begin[MyError]:
  foo *> bar
.rescue:
  case MyError.Derp => ???
  case MyError.Fart => ???

//> using scala "3.3.0-RC5"
//> using lib "org.typelevel::cats-mtl::1.3.1"
//> using lib "org.typelevel::cats-effect::3.4.10"

import cats.*
import cats.effect.*
import cats.mtl.*
import scala.annotation.*

def begin[E]: Begin[E] = ???

class Begin[E]:
  def apply[F[_], A](f: Handle[F, E] ?=> F[A])(using ApplicativeThrow[F]): Body[F, E, A] = ???

class Body[F[_], E, A]:
  def rescue(f: E => F[A]): F[A] = ???

enum MyError:
  case Derp, Fart

def foo(using Raise[IO, MyError]): IO[Unit] = ???
def bar(using Handle[IO, MyError]): IO[Unit] = ???

object Main extends IOApp.Simple:
  def run =
    begin[MyError]:
      foo *> bar
    .rescue:
      case MyError.Derp => ???
      case MyError.Fart => ???

The catch is that it breaks if I add an overload to support the Scala 2 cross-compilable syntax where the Handle is passed explicitly. So I do think we will need a different method name.

armanbilge · 2023-05-11T05:14:52Z

Ha, for fun you can even slap on a guarantee at the end and then it's truly like a try/catch/finally.

begin[MyError]:
  foo *> bar
.rescue:
  case MyError.Derp => ???
  case MyError.Fart => ???
.guarantee:
  IO.unit

armanbilge · 2023-05-11T05:23:53Z

Some more name ideas: allow[Error], anticipate[Error], expect[Error], intercept[Error]

allow[MyError]:
  foo *> bar
.rescue:
  case MyError.Derp => ???
  case MyError.Fart => ???

anticipate[MyError]:
  foo *> bar
.rescue:
  case MyError.Derp => ???
  case MyError.Fart => ???

expect[MyError]:
  foo *> bar
.rescue:
  case MyError.Derp => ???
  case MyError.Fart => ???

intercept[MyError]:
  foo *> bar
.rescue:
  case MyError.Derp => ???
  case MyError.Fart => ???

Edit: I think I really like allow especially when paired with typelevel/cats-effect#3575. Because that makes it impossible to raise errors in F[_]: Concurrent etc. unless someone allows you to 😜

benhutchison · 2023-08-03T04:59:25Z

braceless syntax is increasing in popularity. will this work? if not then how does it look without braces?
Handle.begin[IO, DomainError]:
  foo *> bar
rescue:
  case DomainError.Failed => ???
  case DomainError.Derped => ???

❤️ that we're considering how it works braceless. I'm all too happily becoming a braceless mutant that's losing the ability to synthesize braces..

I'm fine with allow instead of begin if that's what it takes to avoid namespace collisions.

Overall, would really like to use this capability, hit the Merge already :P

djspiewak added 3 commits April 30, 2023 11:04

Implemented submarine error propagation for Handle

c98c2ae

Added headers

1a4e0e8

Collapsed Handle tests and fixed Scala 3 issues

f044fab

armanbilge reviewed Apr 30, 2023

View reviewed changes

djspiewak and others added 3 commits April 30, 2023 15:49

Update tests/shared/src/test/scala/cats/mtl/tests/HandleTests.scala

5dee0bf

Co-authored-by: Arman Bilge <[email protected]>

Update tests/shared/src/test/scala/cats/mtl/tests/HandleTests.scala

07c8aeb

Co-authored-by: Arman Bilge <[email protected]>

Update tests/shared/src/test/scala/cats/mtl/tests/HandleTests.scala

0b8e897

Co-authored-by: Arman Bilge <[email protected]>

armanbilge reviewed May 11, 2023

View reviewed changes

This was referenced Jun 27, 2023

fs2.io.readOutputStream doesn't preserve errors from cats.data.EitherT typelevel/fs2#3246

Open

[WIP] Mostly complete Tracer impl for F -> OptionT typelevel/otel4s#261

Closed

armanbilge mentioned this pull request Jul 30, 2023

WriterT[IO.. losing logs in parEvalMap hints at problem with Concurrent instance for WriterT ? typelevel/cats-effect#3764

Closed

armanbilge mentioned this pull request Aug 3, 2023

Add Raise#fromEither and friends #514

Merged

benhutchison mentioned this pull request Aug 5, 2023

Rebranding Cats MTL to emphasize the Capabilities, not the Monad Transformers #516

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Implemented submarine error propagation for `Handle` #489

Implemented submarine error propagation for `Handle` #489

djspiewak commented Apr 30, 2023

armanbilge left a comment

armanbilge Apr 30, 2023

djspiewak May 1, 2023

armanbilge May 1, 2023

djspiewak May 1, 2023

armanbilge May 1, 2023

armanbilge Apr 30, 2023

djspiewak Apr 30, 2023

armanbilge Apr 30, 2023 •

edited

Loading

djspiewak May 1, 2023

djspiewak commented May 1, 2023

benhutchison commented May 1, 2023

armanbilge commented May 1, 2023

djspiewak commented May 9, 2023

armanbilge commented May 9, 2023

armanbilge May 11, 2023

armanbilge commented May 11, 2023

armanbilge commented May 11, 2023 •

edited

Loading

armanbilge commented May 11, 2023 •

edited

Loading

benhutchison commented Aug 3, 2023

		def apply[F[_], E](implicit ev: Handle[F, E]): Handle[F, E] = ev

		def ensure[F[_], E]: AdHocSyntax[F, E] =


		final class AdHocSyntax[F[_], E] {

		def apply[A](body: Handle[F, E] => F[A])(implicit F: ApplicativeThrow[F]): Inner[A] =

Implemented submarine error propagation for Handle #489

Are you sure you want to change the base?

Implemented submarine error propagation for Handle #489

Conversation

djspiewak commented Apr 30, 2023

armanbilge left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

armanbilge Apr 30, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

djspiewak commented May 1, 2023

benhutchison commented May 1, 2023

armanbilge commented May 1, 2023

djspiewak commented May 9, 2023

armanbilge commented May 9, 2023

Choose a reason for hiding this comment

armanbilge commented May 11, 2023

armanbilge commented May 11, 2023 • edited Loading

armanbilge commented May 11, 2023 • edited Loading

benhutchison commented Aug 3, 2023

Implemented submarine error propagation for `Handle` #489

Implemented submarine error propagation for `Handle` #489

armanbilge Apr 30, 2023 •

edited

Loading

armanbilge commented May 11, 2023 •

edited

Loading

armanbilge commented May 11, 2023 •

edited

Loading