jatcwang/hotpotato

Nathaniel Fischer

@nrktkt

This idea needs some work to be consistent, but it would be nice if there were some helper method that let you move an "inner" error to an "outer" one more easily.
For example (value: EitherT[Future, A :+: B :+: CNil, Result]).ignore(identity[B]) results in an EitherT[Future, A, Result] given B is a Throwable.
This could maybe use a MonadError[Future, Throwable].

Nathaniel Fischer

@nrktkt

That would be a lot more ergonomic than value.handleSomeWith((e: B) => EitherT(Future.failed(e))

Jacob Wang

@jatcwang

that should be easy enough to do

Jacob Wang

@jatcwang

Can't really use MonadError though because it completely hides the error type (It deals with F[A])

Nathaniel Fischer

@nrktkt

Could we do liike

type TheMonadErrorWeNeed[F[_, _], R, E] = MonadError[F[*, R], E]
def ignore[L1, L1Out, E](funct: L1 => E)(implicit monadError: TheMonadErrorWeNeed[F, R, E], ...)

in ErrorTransCoproductOps?

Nathaniel Fischer

@nrktkt

Or I suppose we could just make our own thing like

trait Raisable[F[_, _], E] {
  def raise[L, R](f: F[L, R])(e: => E): F[L, R]
}
object Raisable {
  implicit def eitherTRaisable[F[_], E](implicit monadError: MonadError[F, E]) = new Raisable[EitherT[F, _, _], E] {
    def raise[L, R](f: EitherT[F, L, R])(e: => E): EitherT[F, L, R] = f.flatMapF(_ => monadError.raiseError(e))
  }
}

Jacob Wang

@jatcwang

I'm defining something like

trait ErrorTransThrow[F[_, _]] extends ErrorTrans[F] {
  def raiseError[L, E, R, LL](in: F[L, R]): F[LL, R]
}

I don't think user will want to create an implicit TheMonadErrorWeNeed for every error(s) they want to throw

Nathaniel Fischer

@nrktkt

I don't really understand the ErrorTransThrow. Should raiseError have a second parameter list?

Jacob Wang

@jatcwang

yes it would (need some sort of elimination function). Still working on it :)

Jacob Wang

@jatcwang

@kag0 https://github.com/jatcwang/hotpotato/blob/225cb2f3b6d468fd9f89cd16482669f2d61e7e61/modules/core/src/test/scala/hotpotato/ErrorTransformSpec.scala#L32

Got it working :) Let me know what you think

Nathaniel Fischer

@nrktkt

@jatcwang
Nice, that syntax looks very concise. But what if the LHS error isn't a throwable? It might be more generally useful to let ErrorTransThrow work for any E and/or have dieIf take a parameter L1 => E.

also, would it work to use scala.DummyImplicit instead of DummyParam?

Jacob Wang

@jatcwang

@kag0 nice Didn't know about DummyImplicit :D

I'm wondering what are you going to do with the errors you specified if it's not a throwable? (I don't really want to encourage people do silently ignore errors..)

If you want to transform particular errors into the other type, you can use handleError to handle a subset of the errors and turn them into some other error type? (The result type should be correctly inferred)

Note that I'm thinking of changing the names from handle1, handleSome to mapError1 and mapSomeError

(following ZIO naming convention which I think makes a lot of sense)

Nathaniel Fischer

@nrktkt

so that would look like

thing
  .mapSomeError((e: MyError) => new MyOtherError(e))
  .dieIf[MyOtherError]

That makes sense. Users can always make their own syntax if they want to shorten that up.

As far as non-throwable errors, I'm just thinking of edge cases where maybe the error type is a subtype of Throwable, or maybe the user is possesed to have an Either[FatalE, Either[ExpectedE, Result]] or something.

Jacob Wang

@jatcwang

yeah that'll work. We can provide a mapSomeAndDie but it's probably to keep the API surface small for now.
Not too sure what you mean in the latter paragraph. I'm guessing you mean that the user wants to go from F[FatalE :+: Expected E :+: CNil, Result] to F[FatalE :+: CNil, F[ExpectedE, Result]? You can use flatmapError for that (it's currently named handleSomeWith)

Jacob Wang

@jatcwang

Pushed my changes and tagged it 0.0.5

Nathaniel Fischer

@nrktkt

A concrete example might be like

val before: Either[FatalE, Either[ExpectedE :+: FatalE :+: CNil, Result]] = ???
val after: Either[FatalE, Either[ExpectedE :+: CNil, Result]] = ???

so you're suggesting that a user could do

val after = before.flatMap(_.flatmapError((e: ExpectedE) => Right(Left(e))))

Nathaniel Fischer

@nrktkt

I was thinking the same could be done like

val after = EitherT(before).dieIf[FatalE]

you'd just need to remove the type constraint on E in ErrorTransThrow.extractAndThrow

Jacob Wang

@jatcwang

I guess I've never seen a signature like that, as you'd normally use flatMap and avoid it altogether (especially with the for comprehension support my library provides)

Jacob Wang

@jatcwang

(So to generalize, you want F[E1, F[E1 :+: E2 :+: CNil]] => F[E1 :+: E2 :+: CNil, F[E2 :+: CNil, R]]?

this is quite different from "dying", where you actually "blackholes" certain errors because they are thrown, terminating the whole chain. I cannot remove the Throwable constraint since ZIO instance requires it.

Nathaniel Fischer

@nrktkt

(So to generalize, you want F[E1, F[E1 :+: E2 :+: CNil]] => F[E1 :+: E2 :+: CNil, F[E2 :+: CNil, R]]?

errm, more like F[E1, F[E1 :+: E2 :+: CNil]] => F[E1, F[E2 :+: CNil, R]]. the example might be getting a bit convoluted/confusing.

really I'm just suggesting the typeclass look like

trait ErrorTransThrow[F[_, _], E] extends ErrorTrans[F] {
  def extractAndThrow[L, R, LL](in: F[L, R])(extractUnhandled: L => Either[E, LL]): F[LL, R]
}

then ZIO can be supported with

implicit def zioErrorTrans[Env] =
  new ErrorTransThrow[ZIO[Env, *, *], Throwable] {

    override def extractAndThrow[L, R, LL](in: ZIO[Env, L, R])(
      extractUnhandled: L => Either[Throwable, LL],
    ): ZIO[Env, LL, R] = in.catchAll { errors =>
      extractUnhandled(errors) match {
        case Left(throwable) => ZIO.die(throwable)
        case Right(handledErrors) => ZIO.fail(handledErrors)
      }
    }
  }

Where communities thrive

People

Repo info

Activity