I guess it’s kinda hard to give a general direction on how error handling is supposed to work, since there are many cases where it requires "special" handing. That being said, i follow Roman's blog for advice on how error handling should be, and it has worked great for me. For some reason I took for granted that this way (blog’s) is the most idiomatic, since it depends only on language features without any additional helpers (like Either). I’m not sure what do you mean by "exceptions are too risky to use", but imho: many applications like yours cannot terminate due to an exception (bug, etc), that's where advice controllers (spring terminology, not sure how other frameworks name the pattern) come in play. At least that’s how I handled exceptions (that’s also how the blog advices to use them, it refers to them as top-level framework code). Note: imo, if arrow works for you, then that’s fine too.

I'm obviously biased, so take this with a grain of salt. First of all, Arrow would be happy if anything it covers lands in Kotlin Std, or KotlinX. It has always been made it clear that it favor idioms in the language, or official support through KotlinX. Arrow want to be a unified front on FP / safer code, rather than causing fragmentation like we see in some other languages. If any decisions in this direction is ever made, Arrow will be super excited to drop / migrate whatever it has into the same direction. Friction with the language / eco-system results in poor UX. The more Arrow has embraced the language, trying to get rid of wrapper types like

IO

in favor of

suspend

, embracing DSLs, etc the happier we've become writing FP code in Kotlin (and I think the same goes for Arrow users). Personally, I don't think the language has to make an official recommendation. on Arrow, FP, or any OSS library / framework. is not a one-fits-all solution. I.e. Spring vs Ktor vs Quarkus vs Vert.X vs ... all are great candidates in Kotlin. In some cases I also use

Result

, and in others

Either

, nullable types or whatever fits my use-case best. So an official recommendation might even be counterproductive, "pushing" people to a single solution whilst it might not fit for their use-case. Arrow is also not exclusive around

Either

, and offers many other patterns well known in FP. I am personally not even a fan of the term FP anymore, same for OOP. Since with modern languages these things have faded a bit, and often a mix of put styles is used / found with great success.

Thank you @simon.vergauwen those are all very valid point. I’ve seen arrow team has made tremendous effort for making the API consistent with the direction of Kotlin stdlib. In my opinion as a user of the library, especially around error handling best practices, it provides an elegant solution to that gap in the current Kotlin ecosystem. In my personal view I think this is an opportunity for the language to benefit from absorbing some of the learnings in arrow and adopt it as native linguistic constructs. I agree @George about error handling, global / local exception handlers are useful in that regards. We use spring in production so we had controller advices. However, as the code grows, contributors start to lose context as for origins of the exceptions. Some has been silently caught / rethrown as a different exception and forgot to be handled. We also mistakenly caught wrong exceptions or mistakenly uncaught the right ones… We have probably caught cancellation exceptions and OOME as well, it’s very possible.. We had gone through that exercise in the past… With those learnings, the need of a type with a generic failure is very real. We can’t constantly be paged in 2am in the morning for something that the compiler should be able to help… That’s where we’ve decided to leverage Arrow’s

Either<L, R>

type instead of hand-writing our own. So.. with that said, I’d like to go back to the proposition so to make sure the intention is not lost. Why doesn’t Kotlin have this (imo) highly relevant type in the language? I believe one thing that we all would likely agree is for domain failure states to be modelled as an explicit return type. Exceptions are exceptional, and should only be used for exceptional circumstances.

catch { }

is possibly dangerous as it might catch other unwanted exceptions such as

CancellationException

or

OutOfMemoryError

. Let’s introduce something like

Result<E, T>

- instead of having throwable as its failure type, users will have the liberty to type the error channel. Something like below hypothetical type:

// Sorry, the name clashes with Result<T>, 
// decision of using value class, and identifier orders are hypothetical implementation detail 
// the language implementer can choose to implement this as sealed type or native union type accordingly
value class Result<E, A> private constructor(val value: E | A) { 
  fun valueOrNull(): A? = ...
  fun isSuccess(): Boolean = ... // kotlin contract, implies value is A
  fun isFailure(): Boolean = ... // kotlin contract, implies value is E
  // etc...
}

Afterwards perhaps we can then leverage the kotlin type-safe builder to then create a DSL, similarly to how kotlinx

flow { }

and Arrow’s

either { }

can be constructed and composed. Here I’m drawing inspirations from Arrow:

interface ResultContext<E> {
  fun fail(failure: E): Nothing
  fun <B> Result<E, B>.valueOrFail(): B // this extension name is hypothetical, in Arrow it's called bind()
}

inline fun <E, A> result(@BuilderInference fn: ResultContext<E>.() -> A): Result<E, A> = ...

// in the caller's code
suspend fun getManagedUser(id: UserId): Result<Fail, ManagedUser> = result {
  val user = getUser(id).toResult { Fail.UserNotFound }.valueOrFail()
  val managedStatus = getManagedStatus(user)
  
  if (!managedStatus.isManaged) {
    fail(Fail.UserIsNotManaged)
  }
  
  ManagedUser(user, managedStatus)
}

Having this type will solve a lot of problems and possibly alleviate some confusion on the topic of error handling. I want to understand more on where is the language heading towards? On this regards, I 100% agree to this.

Personally, I don’t think the language has to make an official recommendation. on Arrow, FP, or any OSS library / framework. is not a one-fits-all solution. I.e. Spring vs Ktor vs Quarkus vs Vert.X vs ... all are great candidates in Kotlin.

The reason why I mentioned recommendation is perhaps because in my view error handling is a common principle of software development lifecycle. One can choose how to handle errors which is agnostic to frameworks, but adhere to best practices and principles. In my opinion Arrow provides good example for that and some patterns (e.g. the

either { }

builder) may need to be brought into attention of a broader audience. i.e. it’s not recommending a library per se but recommending the approach taken to be aligned with idiomatic kotlin. If I were to draw some parallels between languages which employs a similar principle around exceptions. Rust has this principle, and also a solution. It provides a language level solution with

Result<T, E>

which is either a

Ok<T>

or

Err<E>

- a typed error channel. This allows segregation of domain-level errors

E

and encourage safe programming with values, translating and handling errors between boundaries - i.e. each boundaries would have different

E

types. Kotlin in other hand has the right principles but lack clear guidance or language solution. Would be great to get some alignment on the solution might look like. I won’t be surprised if we find many users may have tried reinventing or have reinvented this wheel multiple times… This is where I believe we can benefit from a slightly clearer guidance.

Error-handling is not a solved problem in any programming language. Even Rust, which has a standard

Result<T, E>

type used widely throughout its ecosystem, has issues. There is a wide divergence between library authors who want to provide actionable and recoverable errors (leading to solutions like thiserror to help reduce the boilerplate required), and application authors who want manage many different errors without having to wrap all of their dependencies' error types into a common hierarchy (leading to other solutions like anyhow - from the same author!).

@ephemient Thank you for giving a very concrete example with the Error tree in the application! Much appreciated. Yeah I agree that each application will inevitably define a particular way which fits the most to its needs. I’d like to point to an interesting observation though. Isn’t it then possible for the

XyzResult

type in that case be modelled as either a failure or success with generic type? i.e. • wouldn’t

NetworkResult<out T>

would then be

Result<NetworkError, NetworkValue<T>>

? • wouldn’t

CacheResult<out T>

be

Result<CacheFailure, CacheSuccess<T>>

? • and

DialogResult<T>

is

Result<DialogFailure, Dialog<T>>

The reason why I point this out is because all of a sudden because result is a provided type, we can leverage kotlin’s very own type-safe builder to compose this ergonomically and handle the error types safely between domain boundaries. consider

interface ResultContext<E> {
  fun fail(failure: E): Nothing
  fun <B> Result<E, B>.valueOrFail(): B // this extension name is hypothetical, in Arrow it's called bind()
}

inline fun <E, A> result(@BuilderInference fn: ResultContext<E>.() -> A): Result<E, A> = ...

then we can write something like below where translation between domain boundaries can happen organically

suspend fun getPositiveDialog(id: DialogId): Result<GetPositiveDialogFailure, CustomDialog> = result {
  val dialogData: DialogData? = getDialogDataFromCacheById(id).map { it.value }
    .recover { getDialogDataFromNetworkById(id).map { it.value } } 
    .mapFailure { failure -> /* map the getDialog failure to GetPositiveDialogFailure */ }
    .valueOrFail()
  
  ensureNotNull(dialogData) {
    GetPositiveDialogFailure.DialogNotFound
  }
  
  // kotlin contract, dialogData is no longer null, update cache async
  cacheUpdaterCtx.launch { updateCache(dialogData) }
  
  val dialog: Dialog<CustomDialog> = extractDialog(dialogData)
    .let { convertDialog<CustomDialog>(it) }
    ?: fail(GetPositiveDialogFailure.DialogConversionFailure)
  
  when (dialog) {
    is Positive -> dialog.value // CustomDialog
    is Neutral -> GetPositiveDialogFailure.NeutralDialog
    is Negative -> GetPositiveDialogFailure.NegativeDialog
  }
}

yes, and would be pretty similar to Rust: you have a standard

Result

type, but every module has its own

Error

hierarchy. it does mean you get standard

map

functions etc. for the outer

Result

(ditto Arrow's

Either

) but it doesn't help at all with converting the errors between domains. our codebase has custom mappers going up the chain, and those would still remain even with a typed

Result

or

Either

.

Ah yes. the conversions between domain types is going to be inevitable and is definitely a drawback / benefit depending on how you look at it when one has to deal with types that crosses multiple boundaries. I guess an analog in the previous java life would be catching an exception and rethrowing a different one

if we had union types,

Result<T, E1 | E2 | E3 ...>

then it would be like Java's checked exception propagation (and actually Rust kind of allows you to do that, where

?

will automatically

.into()

if possible) but there's a lot of other impacts to the language with that

If I were to hypothesize the interop to java will be exactly like how other generic types would be treated. Considering if this type is the one in question:

value class Result<E, A> private constructor(val value: E | A) { 
  fun valueOrNull(): A? = ...
  fun isSuccess(): Boolean = ... // kotlin contract, implies value is A
  fun isFailure(): Boolean = ... // kotlin contract, implies value is E
  // etc...
}

then yeah java code can just call

result.valueOrNull()

as pretty much how it does it with java very own

Optional<T>

Taking a step back. It’s actually this conversation that I’m after. Notice how we finally are both talking about domain boundaries and how errors should be translated, by whom, where, and when. Not only that - we can compose complex control flows of programs by leveraging kotlin language with

result { }

builder. This is what I’m after of this conversation. Having some type that has a typed error channel gives this.

I'm very glad to hear, since that was exactly our goal! I don't consider it very FP-ish either, as I mentioned in my first comment. It just provides some abstractions, and DSLs for dealing with typed errors. Similarly it offers DSLs for resource safety, saga pattern, etc rather than using heavy FP concepts with transformers, typeclasess, etc. Like I said, I am very biased but I consider the APIs and DSLs we're not proposing to be idiomatic. Everything has taken inspiration from either Kotlin Std & KotlinX in addition to community feedback.

That’s good to hear. I do see parallels in kotlinx and stdlib especially with

mono { }

or

flow { }

builders. So I do believe the way errors are handled with types and values instead of exception to be idiomatic. In which case.. there is a definite gap in the language about a missing

Result<E, A>

type. Yes Arrow did fill that gap, but I think this might be because it’s a systemic problem.. I’d like to understand better the reason why isn’t this type available in the kotlin library. Surely there is a reason behind it and it has probably being considered as I do find articles and comments online and even in the blog itself that asks for this. If this type is introduced to the standard library or as part of opt-in package in kotlinx.typesafe. That would solidify this and alleviate all the ambiguity on the best practice on error handling and how that should be done in Kotlin.

I believe there are other production applications like ours for which exceptions are too risky to use

Exceptions are present on the JVM, and even if you never throw any, you always have to remember that anything could throw an exception anywhere. So there is no (sane) way to completely get rid of exceptions. In general people setup exception handling at a high level (usually in the main framework they're using) to deal with unhandled exceptions, and avoid app death where necessary. Of course this doesn't mean we should use exceptions everywhere for error handling. As @ephemient pointed out, you may represent business-level errors with sealed classes (or nullability for the simplest cases). From what I have gathered, Roman's blog post is describing the idiomatic way of handling errors in Kotlin at most levels. I recommend also reading the initial KEEP for the design of

kotlin.Result

, which describes the intended style of Kotlin as well.

I see, noted about that I wasn’t aware that style has a term! Thanks for giving that enlightenment. Out of curiosity. Hypothetically if say we pivot to the direct approach, how would you recommend me to approach error handling in direct-style programming? Say I have this toy function to bake a cake, how would we rewrite this into a direct style?

suspend fun bakeCake(...): Outcome<Fail, Cake> =
  outcome { 
    val butter: Butter = buyButter(...).valueOrFail()
    val carrot: Carrot? = buyCarrot(...).valueOrFail()
    val sugar: Sugar = buySugar(...).valueOrFail()
    val flour: Flour = buyFlour(...).valueOrFail()

    carrot?.let { carrot -> 
      ensure (carrot.isFresh()) {
        Fail.StaleCarrot
      }
    }

    bakeCarrotCake(recipe, carrot, sugar, butter, flour).valueOrFail()
  }

https://youtrack.jetbrains.com/issue/KT-186/Support-pattern-matching-with-complex-patterns#focus=Comments-27-7071428.0-0 Maybe something interesting to share here. Roman mentions here that Kotlin favors undeep ADTs. So if you prefer working with railway-oriented programming as @Joffrey mentioned I think the new style Arrow is already promoting that and context receivers will help exactly with that. Having to nest "success" into a layer of introduces more nesting. Including, or combining multiple of these types becomes increasingly problematic since it either requires nesting them in each-other, or redefining and duplicating entire hierarchies to combine/flatten them. This can be completely avoided with the style Arrow offers. Since you can horizontally compose errors, and doesn't require wrapping "success". As I mentioned above:

fun Raise<String>.one(): Int = 1

vs

fun one(): Either<String, Int> = 1.right()

. There is no need for

bind

or

valueOrFail

as shown in the example from @mitch. This sadly currently occupies the receiver, but with context receivers that is resolved.

context(Raise<UserAlreadyExists>)
fun User.save(): Unit = ...

context(Raise<UpdateRejected>)
fun Remote.createProfile(
  user: User,
  update: Update
): Unit = ...

context(
  Raise<UserAlreadyExists>,
  Raise<UpdateRejected>
)
fun serviceMethod(...): Unit {
  ...
  user.save()
  ...
  remote.createProfile(user, ...)
  ...
}

This supports all patterns of railway programming, still supports the style of coding that Mitchell shared above, and is more in line with more modern functional languages are evolving towards. It completely eliminates the need for

flatMap

or more complex patterns such as monad transformers, traverse, etc. It's also future proof with other potential upcoming features, such as union types:

context(
  Raise<UserAlreadyExists | UpdateRejected>
)
fun serviceMethod(...): Unit

As I mentioned, IMO nothing is a one-fits-all solution, that is something I definitely learned as having worked half my career as a fanatic OOP Java developer. I guess that also seems to be the conclusion of this discussion. I think both styles fit well in Kotlin, and I am proud of the improvements we made in Arrow.

I need my mindblown emoji 🤯 :mind-blown:

My pleasure @mitch ☺️ You can find more details, and examples on the new website as well. And of course as always, more than happy to discuss more in detail in #arrow as well 😉

Let me add that we are explicitly keeping this use-case in mind when we design context receivers. Long story short,

context(Raise<UserAlreadyExists>)

is a kind of coeffect — a “capability to raise an error” that the function requires from its context. Coeffects are totally equivalent to effects, that are traditionally used in functional languages to model exceptions and things like this. However, coeffects (contexts) are more ergonomic and fit way better into Kotlin programming style.