If I have: ```fun foo() = effect { raise(DomainError) } fun bar() = effect { val context = .......

# arrow

[dave08]

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. }) { ... }

[simon.vergauwen]

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)) }
}

[dave08]

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?

[simon.vergauwen]

Well, if you have access to context outside of effect { } you can also do foo().recover { e: DomainError -> raise(WrappedError(context, e)) }

[dave08]

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

[dave08]

🙃 I guess I'll have to survive one extra level of nesting... thanks!

[simon.vergauwen]

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.

[simon.vergauwen]

IMO: nesting DSLs is Kotlin's super power 😅 If you compare it to other patterns in other languages.

[dave08]

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" 😊

[simon.vergauwen]

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.

[dave08]

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.