I've just run into an interesting problem related to

raise()

. The code in my next message references different

catch()

functions, and their return type and semantic is different as well. How should I refactor the second

eagerEffect {}

call to make it execute

fold()

in the background?

I'm not sure if that is a problem, the API was designed like this intentionally 😅 Very open to feedback of course! 🙏 There is always top-level, and DSL based behavior where the API and signature is the same. The "correct" way of call

f2

inside

Raise<Err1>

would be, and I would actually suggest the same for the

f1

.

context(Raise<Err1>)
fun f() {
  catch({ f1() }) { raise(Err1) }
  recover(
   { f2() },
   { _: Err2 -> raise(Err1) }
  ) { _: Throwable -> raise(Err1) }
}

There should never be a need to wrap in

eagerEffect

or

effect

But on the top level, where no

Raise<R>

is available yet, I should use

eagerEffect {}

and

effect {}

, shouldn't I?

Not sure which

alpha

you're on but on the latest

1.1.6-alpha.44

you should be able to just call following code on the top-level:

fun main() {
  recover({ f() }) { e: Err1 -> println(e) }
}

feedback

For me, code like

recover(
   { f2() },
   { _: Err2 -> raise(Err1) }
  ) { _: Throwable -> raise(Err1) }

is not very readable. Maybe it's just me but I would prefer a syntax closer to Kotlin's try-catch, like

attempt { f2() }
.handle { _: Err2 -> raise(Err1) }

// and

attempt { f2() }
.handle(
    catch = { _: Throwable -> raise(Err1) },
    recover = { _: Err2 -> raise(Err1) }
)

Something like the following? (Quick and dirty prototype, only with

recover

without

catch

, etc.)

context(r@Raise<R>)
@RaiseDSL
inline fun <R, E, A> (Raise<E>.() -> A).handle(
    @BuilderInference recover: Raise<R>.(E) -> A
): A {
    val action = this
    return fold<E, A, A>({ action(this) }, { throw it }, { recover(this@r, it) }, { it })
}

fun <R, A> attempt(@BuilderInference block: Raise<R>.() -> A) = block

EDIT: as I read it again, I have reinvented the wheel, this is very similar to the syntax of

effect {}.fold(...)

! 🙂

Yes, that's the syntax you already get from

effect { } recover { }

,

effect { }.recover({ }, { })

or

effect { } catch { }

. (same for

eagerEffect

).

"problem" is that you need to use

effect

or

eagerEffect

It's not a problem for me, its usage results in very readable code imho. What confused me a bit was:

that's the syntax you already get from

effect { } recover { }

... works in both DSL, and top-level form

vs

There should never be a need to wrap in

eagerEffect

or

effect

But if I can choose between

recover({}) {}

and

effect {} recover {}

I choose the latter for sure 🙂 This leads us back to my original question, where those "conflicting"

catch()

functions are a bit confusing for someone new to the "raise() mechanism". Thanks for the explanations!

In the IDEA the first one should've coloured in the DSL syntax style, while the latter didn't. That should've visually indicated that two different methods were being called. The first one works in DSL style since your'e calling

catch

on

Err1

inside

Raise<Err1>

. The second one didn't since it's of type

Err2

.

But if I can choose between

recover({}) {}

and

effect {} recover {}

I choose the latter for sure 🙂

There is nothing preventing you from doing so,

recover

is the base operation. Calling

effect { f() } recover { }

is literally calling

recover({ effect { f() }.bind() }) { }

. What I meant with:

There should never be a need to wrap in

eagerEffect

or

effect

Beside preferring

effect { } recover { }

which I'll put aside as personal syntax preference, there is never a need to return

Raise<E>.() -> A

or

suspend Raise<E>.() -> A

as a return value when using context receivers. I am personally more a much bigger fan of

recover({ f() }) { }

because it's more consistent, having many different syntaxes available is confusing. So taking into account your feedback I would be in favor of removing the `recover`/`catch` DSL functions for `Effect`/`EagerEffect` and that changes your originally snippet to:

context(Raise<Err1>)
fun f() {
  val r1: Unit = eagerEffect {
    f1()
  }.catch { // 1
    raise(Err1)
  }.bind()

  val r2: Raise<Err2>.() -> Unit = eagerEffect {
    f2()
  }.catch { // 2
    raise(Err1)
  }//.bind() not available
}

What do you think about that? It's indeed more consistent, but I thought having `catch`/`recover` auto-bind and colouring it with DSL syntax in IDEA would be sufficiently clear.

I have to think about it, now that I understand the whole thing better :) But I think • "autobind" seems to be a good feature, it is good that an explicit

bind()

call is not needed (especially because it won't help in my biggest problem, that in my example

f1()

is effectively invoked while

f2()

is not, in the latter case a

fold()

call would be needed as well) • now I see why `recover()`/`catch()` is more consistent I'll be back :)

Small POC making some changes to visual it better, https://github.com/arrow-kt/arrow/pull/2968

Do I understand correctly that my example would look like the following (with the

catch {}

calls being optional)?

Yes, and no 😅 On

f1

you can call

bind()

to avoid having to do manually re-raise the

Err1

error using

getOrElse { raise(it) }

. For

f2

you need to transform

Err2

to

Err1

by unwrapping using

getOrElse

and then you have option to provide a fallback value or raise

Err1

. I added

e: Throwable

to

catch

to show its working over the exception channel not the error one.

context(Raise<Err1>)
fun f() {
  val r1: Unit = eagerEffect {
    f1()
  }.catch { e: Throwable ->
    raise(Err1)
  }.bind()

  val r2: Unit eagerEffect {
    f2()
  }.catch { e: Throwable ->
    raise(Err1)
  }.getOrElse { e: Err2 -> raise(Err1) }
}

I think I still have to learn to be able to help you in the decision. So let's use the syntax you find better 😉🙂

Any feedback is valuable ☺️ What do you think about what is discussed here, and proposed in the PR? Any feedback from anyone else is also appreciated 🙏

On

f1

you can call

bind()

to avoid having to do manually re-raise the

Err1

error

I didn't mean to "reraise" but to simulate that

Err1

can be raised at that location as well.

improves the consistency of the API

Yes, after our discussion I feel the same and I think consistency is key for easier understanding and better readability but lets let it sink in for a couple of days and await some more feedback (hopefully 🤞).

(sorry not fully followed the thread) but a small comment would be that for

Effect

,

getOrElse

to me hides the fact it’s lazy. Possibly a better name might be

invokeOrElse

to align with

invoke()

which conversely requires the

Raise<E>

context receiver.

Well, one is

suspend fun

and the other one is not 😅 The name is indeed not very explicit in that regard, but for me the rationale is that if you'd translate it to boxed types / transformers it'd look like:

fun IO<Either<E, A>>.getOrElse(f: IO[A]): IO[A]

. So it's still lazy, pure and safe.

Any feedback from anyone else is also appreciated 🙏

Just a suggestion: maybe you should ask for feedback in a separate thread, because this thread has become bloated because of my questions - sorry 🙂

Agreed - my main thought though is to be explicit in the difference between an

Either

that already contains a value (or error) that you’re

get

’ing (or defaulting), and an

Effect

which can be called multiple times potentially with different results (success or failure) on each call. I’ve usually find that’s the confusing aspect of

IO

is that it can at times seem to be a value (and indeed could be a pure value) or it could be an effect. I like that it’s clear based on signature/type that Effect and Either differ in that, and it should ideally be clear when consuming them that they’re different

When turning

IO

->

suspend

and

Either<E, A>

to

Raise<E>.() -> A

you get

suspend fun Effect<E, A>.getOrElse(f: suspend (E) -> A): A

. No?

Ah I see what you mean. I was thinking in terms of

Effect

itself being the

IO

and didn’t think

getOrElse

was

suspend

Yes, indeed. Sorry if I was unclear 😅 So you're forced to call it from another

suspend fun

, or another

Effect

. Effectively only resolving the

Raise<E>

constraint.

I personally like the autobind. At the same time I realize it may be confusing that the actual function changes depending on enclosing context and it's type. A compromise may be to rename one of the functions? e.g. the autobind function could be named

invokeWithCatch

? That would reflect exactly what it does and avoid name clashing with the

Effect

Thanks for the feedback @phldavies. Does

getOrElse

makes more sense in this case? I feel it's the same as

toEither

given the constraint of

suspend

. @Francis Reynders thanks for the feedback. I try to follow a general rule which is if the alias name is longer or similar in length as the composition of names of the smaller parts if often doesn't really offer a true benefit. In this case I think it doesn't make sense. I.e.

effect.invokeWithCatch {
  // ...
}

effect.catch {
 // ...
}.bind()

The latter is/seems shorter in API name, and I think this would also result in a more consistent API. If we consider that introducing new names increases API surface complexity. WDYT?

@simon.vergauwen: Understood and good point. In this case however the

.catch

.bind

combination seemed less accessible for newer users (such as myself), but understanding

bind

should probably be considered a basic understanding of the lib.

In this case however the

.catch

.bind

combination seemed less accessible for newer users (such as myself)

I also don't like the explicit

bind()

... It may be very logical for someone with a strong FP background but for me "bind" means almost nothing in this context (I bind what to what? 🙂 ).

Well, it really depends on what you're doing.

bind

can be always be avoided when working with context receivers, but then you need to fully embrace DSL style.

object Err1
object Err2
context(Raise<Err1>) fun f1(): Int = 1
context(Raise<Err2>) fun f2(): Int = 2

context(Raise<Err1>)
fun example() : Int {
  val w = f1()
  val x = catch({ f1() }) { _: Throwable -> raise(Err1) }
  val y = recover(
    { f2() },
    { _: Err2 -> raise(Err1) },
    { _: Throwable -> raise(Err1)  }
  )
  val z = recover({ f2() }) { e: Err2 -> raise(Err1) }
  return w + z
}

Given the original example ignored all the results (

Unit

) everywhere then the compiler cannot help you catch any missing

bind

since

Unit

accepts

Unit

but also

Effect<E, A>

values. If you would add

: Int

in the return types like I've done here then the code wouldn't have compiled.

but I feel it looks a bit weird

You wrote earlier that you prefer using

recover({}) {}

the most. As I experiment with the API I found that besides

effect {}.recover {}

I like

recover()

as well, what I don't like is its name 🙂 Wouldn't it be a better name

execute()

or

perform()

or

invoke()

or something else? I started using it like this, and although it is a little bit verbose, it is very well readable imho:

recover(
    action = { ... },
    recover = { ... },
    catch = { ... }
)

It reflects the "two layers" of error handling very well...

The most base operation, from where all of these APIs are derived is

fold(action, catch, recover, transform)

. So would make most sense to have an

fold

operation with

::identity

as a default parameter for

transform

but not sure that won't conflict with other signatures 🤔 The reason there is a

recover

operation with a

catch

overload is to avoid having to write:

catch({
  recover(action, recover)
}, catch)