A modern programming language that makes developers happier.

kotlinlang

Hi!. In this video (at the playback point on the link) an alternative way to model domain errors with extension functions and not requiring sealed / shared inheritance was hinted: <https://www.youtube.com/watch?v=g79A6HmbW5M&amp;t=1786s> Is that on any code example / talk done afterwards already? I’m experimenting with things there, but would like to know the approach suggested on the talk cause it may be better / different and it would be nice to see before choosing something.

Hey <@U52EB8K1P>,

Great question. I didn’t have enough time to show everything in the webinar sadly :stuck_out_tongue_winking_eye:

Let’s say you have the following:

```data class DatabaseError(val error: Throwable)
data class NetworkError(val error: Throwable)```
Normally you’d combine them under a common parent using `sealed interface MyError` so that you can have `Either&lt;MyError, A&gt;`.

But with context receivers you can do:

```context(
  EffectScope&lt;DatabaseError&gt;,
  EffectScope&lt;NetworkError&gt;
)
suspend fun program(): A```
This can be good for multiple reasons:
• Doesn’t require inheritance, or common parents. So it allows you to keep clear seperation of concern between errors.
• It allows you to resolve specific errors, or install error handlers for specific types, wherever you want.
I.e. you can resolve `DatabaseError` but leave the `NetworkError` for another layer.

```context(EffectScope&lt;NetworkError&gt;)
suspend fun programOrNull(): A? =
  effect&lt;DatabaseError, A&gt; {
    program()
  }.orNull()```


I need more time to make content around these topics :see_no_evil:

thanks for the quick reply!, that certain looks cool :ok_hand: Sadly I can’t use context receivers yet on production code (even JetBrains says so). I thought you meant something with extension functions (like manual exhaustive folds) which I also tried but did not arrive yet at anything super clean / low maintenance. Maybe I need to wait then for context receivers to become stable, looking forward to that! :smile:

The only other way I know this is possible is by using something like `Coproduct` or `Union` (`abstract common parent`) in the `Left` side, but that typically doesn’t result in less boilerplate or cleaner code than if you use a `concrete common parent`.

yes, my other compromise solution would be to have `DomainError` as a shared type across compilation modules and just check on subtypes I can handle at the specific effect (or map left to something else). That may be what I would go for since the attempts to fold over not sealed hierarchies is doubtfully better. Some subtypes of DomainError when contained within a single module could still be sealed too, like you do in your webinar code with subtypes of DomainError that are also sealed :ok_hand:

Awesome!!! Very useful for me. Now I know how to use Context Receiver. Thanks <@U0RM4EPC7>