If I have:

fun foo() = effect {
  raise(DomainError)
}

fun bar() = effect {
  val context = ....
  val result = foo().bind()
}

data class WrappedError(val context: Context, val error: DomainError)

// elsewhere
bar().fold({ e -> // I need e to be WrappedError but I can only get the context in bar() ... and foo() raises DomainErrors w/o the context. }) { ... }

So

bar

should return

Effect<WrappedError, ?>

? You can use

recover

inside of

effect { }

(or as top-level anywhere else).

fun bar() = effect {
  val context = ...
  val result = recover({
    foo().bind()
  }) { e: DomainError -> raise(WrappedError(context, e)) }
}

So I'd need to surround the whole inside of the effect block with recover...? I wonder if there's a variant of effect { } that allows that for the whole block?

Well, if you have access to

context

outside of

effect { }

you can also do

foo().recover { e: DomainError -> raise(WrappedError(context, e)) }

Yeah, that's the little problem here...

Nesting is the price we pay for Kotlin DSLs. I personally don't mind it. you can always hide it in an additional function. So it's not the same as callback hell.

Yeah, true. But in certain cases it improves readability, and in others reduces it... I guess it all depends where. But it's a good point that in those cases, it can be hidden in a function... I'm still getting used to "FP"s "create a function to avoid imperative programming" 😊

Not sure I understand that 🤔 This is the same in all of Kotlin, no? It's similar to

with

,

apply

,

?.let

,

withContext

,

withTimeout

, etc. Unrelated to FP, or OOP.

In this particular function, some of the nesting is not as general a function as

with

or

apply

, it won't necessarily be reused, the function just speaks the domain language better (and at the same time avoids some of the nesting...). I just didn't bother separating it until I got to this nesting.