Ergonomics of Raise need improvement

[benhutchison]

I have been porting some code written in terms of a concrete effect Either[String, A] to an abstracted effect with Raise/Handle, that is F[_]: Raise[*, String]

The experience reveals that Raise is not programmer-friendly in some frustrating ways.

I try to port this valueThru operator over HOCON Config objects, which:

• extracts a field from the config at a given path
• if path exists, attempts to parse it with a fallible function extract
• if path doesnt exist, either fallback to a default if one is provided, or else fail

    def valueThru[T](path: String, extract: (Config, String) => Either[String, T], optDefault: Option[T] = Option.empty): Either[String, T] =
      if cfg.hasPath(path) then extract(cfg, path)
      else optDefault.toRight(s"Not found: '$path' in ${cfg.origin().description()}")

The rewrite of this code to F[]: Raise is problematic:

   def valueThru2[F[_]: RaiseS as R, T](path: String, extract: (Config, String) => F[T], optDefault: Option[T] = Option.empty): F[T] =
      if cfg.hasPath(path) then extract(cfg, path)
      else R.fromOption(optDefault)(s"Not found: '$path' in ${cfg.origin().description()}")

Hits compiler error:

No given instance of type cats.Applicative[F] was found for parameter F of method fromOption in trait Raise

where:    F is a type in method valueThru2 with bounds <: [_] =>> Any

The problem is that the Raise typeclass offers fromOption but it can't get by without a little help from its Applicative friends. It only has a Functor internally and can't provide the needed pure to lift the option contents.

Also: I don't love the syntax. 4 terms where the original was 3, plus the need for an as R in the context bound (and even that needs recent Scala 3.x).

I feel like the API design hasn't started by asking "what does the programmer, the end-user, actually want?".

• They have an Option, they want the thing inside it.
• Raise an error if it's not there, want control over the error.

Well that reminds me of the age-old option.getOrElse(throw new Exception("My message")) from the standard library .

To me, the API I want is an extension method on Option[A], orRaise(e: E): F[A] that's available when either

1. A Handle is in scope (Handle extends Raise and Applicative)
2. A Raise and an Applicative is in scope

If offering both leads to implicit ambiguities, I'd take the 1. only. I'm doubtful how much use Raise will see without Handle in the wild.

[lenguyenthanh]

Hey Ben, I totally agree with you that Raise (and the submarine) need to improve a lot to make it more convenient. And in order to do that we need feedback from early adopters like you (thank you so much for trying ❤️ )

For the first problem, as your reasoning (Raise only requires Functor), I think it's reasonable to add Applicative constraint in the function description.

For the second one, We can add some syntax for Raise to make it more "fluent", so we can rewrite your example as below:

def valueThru2[F[_]: RaiseS: Applicative, T](path: String, extract: (Config, String) => F[T], optDefault: Option[T] = Option.empty): F[T] =
  if cfg.hasPath(path) then extract(cfg, path)
  else optDefault.raiseIfNone(s"Not found: '$path' in ${cfg.origin().description()}")

// prototype for Raise's syntax
extension[A] (option: Option[A])
  def raiseIfNone[E, F[_]: [F[_]] =>> Raise[F, E]](ifNone: => E): Applicative[F] ?=> F[A] =
    option.fold(Raise[F, E].raise[E, A](ifNone))(Applicative[F].pure)

Do you think this will iron out some ergonomic issues with Raise?

[benhutchison]

Hi @lenguyenthanh, thanks for your response.

Do you think this will iron out some ergonomic issues with Raise?

Yes, I would make the Option case quite convenient. I'm using a similar extension here and feel it adds value.

Separately, I hit what I consider to be another "ergonomic issue". Sometimes I don't want to be forced to explicitly rescue my errors. I just want to let those Submarines bubble up to the top level as just another throwable.

In my case, I'm using E=String rather than any fancy error hierarchy, and the main benefit of Raise/Handle is to push the burden of wrapping up error msgs down to the framework. For the longest time I always wrote a method that wraps up a String as a Throwable but I'd prefer to get away from that, honestly, for aesthetic reasons more than anything.

So I'd like to have option for something like:

Handle[F, E].allow(body).rethrow //bubbles up the submarines

[djspiewak]

So I'd like to have option for something like:

Handle[F, E].allow(body).rethrow //bubbles up the submarines

Wouldn't it be better then to just have your errors extend Throwable? Submarine isn't a particularly useful type, so if things are bubbling up to the top level, just about the only thing you'll be able to do with it is printStackTrace

[benhutchison]

My intent is that a string-ified rendition of E gets printed to the console for uncaught errors. That seems achievable. Submarine is a case class so its toString will toString on E. (In my apps, E=String anyway)

It would be possible to formalise that somehow, like capturing a Show[E] at rethrow.

I ideally want Throwable out of my applications, only showing up as an unexpected error occasionally thrown by legacy code.

On Scala.js and Scala native Throwable is an imposter. Even on the jvm, the stack trace is often useless in CE, and the thrown-exception execution mode goes unused. So it ends up a clunky typed-wrapper around a String.

[djspiewak]

I don't have any objection to exploring it! I'd prefer to keep Submarine fully internal, but maybe we could have a combinator which takes an E => Throwable and just re-raises that?

[lenguyenthanh]

Handle[F, E].allow(body).rethrow //bubbles up the submarines

This a valid use case, but rethrow seems too convenient and I don't think we should encourage it.

And I think we should customize Submarine.toString (and/or Sumarine.getMessage) to clarify what it is in case of unintentional leak as #648 issue.

I'd prefer to keep Submarine fully internal

Agreed

but maybe we could have a combinator which takes an E => Throwable and just re-raises that?

Handle[F, E].allow(body).rethrow(E => Throwable) looks good to me

[benhutchison]

Handle[F, E].allow(body).rethrow(E => Throwable) looks good to me

Yes that's a reasonable option.

The other approach would be to accept that the Submarine throwable is part of the public API of the Raise/Handle machinery, and design it to ensure it emits reasonable error Strings in the event it bubbles to top.. Then you don't have to re-wrap it into yet another exception to bubble up.