What is the current take on Kotlin's native Result vs eg Arrow Either/Try? I've used Either/Try in my previous team, about to join a team that prefer using Result instead. They seem kinda similar to me (Result needs throwables as errors which is a bit different but whatever) but then there are people that claim that Kotlin devs themselves advocate against using Result in your business code as it will catch all exceptions, which isn't really desirable (see https://stackoverflow.com/questions/70847513/when-and-how-to-use-result-in-kotlin)

You’ll notice that

Result

only has one generic parameter, where

Either

has two. That means that

Either

can model everything that

Result

can, but

Result

cannot model everything that

Either

can. If you need type information about your errors,

Result

will not help you.

to be clear, I don't really agree with @elizarov when he says the following (because it flies in the face of functional error handling and moving trivial business errors to compile time, instead, explicitly advocating turning them into exceptions that blow up in runtime... imo, exceptions should be just that, exceptional, things like out of memory error etc that can't be recovered from, and other regular errors should be regular objects like any other)

The first and foremost use of exceptions in Kotlin is to handle program logic errors. Exceptions are used to check preconditions and invariants in code that static type system cannot track down during compilation. For example, if you a have a function that updates order quantity that must be always positive by the business logic of the code, then you might write something like:

/** Updates order [quanity], must be positive. */
fun updateOrderQuanity(orderId: OrderId, quantity: Int) {
    require(quantity > 0) { "Quantity must be positive" }
    // proceed with update
}

Calling this function with a negative or zero quantity indicates a logic error in some other place in the code and throws an exception. The same happens when you try to get an element by an out of range index from a list, divide by zero, etc.

(https://elizarov.medium.com/kotlin-and-exceptions-8062f589d07)

Yes, I don’t see

Either

going anywhere. It has many use cases that aren’t addressed by the

Result

type.

Agreed, I do think Either is superior to Result or just throwing exceptions, so I'm glad it's not going anywhere, lol That said, in case you weren't able to use Either, what's your take on Result as the next best thing? I think it's positive that it provides Either like functionality albeit not as flexible or powerful, but it's true that it's negative that it forces you to turn everything, even trivial business errors, into exceptions + it potentially catches far more than desirable... (but even then, intuitively I'd say that's still preferable over just throwing exceptions for everything... even if you end up catching an outofmemory error in your business code, at the resource layer you can just look for your business errors, return 4xx or whatever for them, and 5xx and log error for everything else)

Normally if I’m using `Throwable`s I throw them, and if I’m using

Either

then my

Left

type is typically some very descriptive sealed type that is not a

Throwable

. The use case for

Result

, where you want to use a

Throwable

but not throw it, is in my experience a fairly small intersection. It comes up occasionally in framework code, where you want to shuttle an exception from one place to another. This is actually what it was designed for (specifically for the behind-the-scenes implementation of coroutines). But in my experience it isn’t typically relevant for day-to-day code.

What you're describing is exactly what I've been doing at previous gigs. I make sealed error classes for expectable business errors eg on a GET user id 555, at db layer we find out there is no such user (there's no way to guard against this with validation like Roman seems to think) - that's sealed error type UserNotFound so the resource layer looks something like

@GET
fun getUser(id: Int) : User {
    return userService
        .getUser(id) //Either<GetUserError, User>
        .fold({200(it)}, {when UserNotFound 404 etc etc map other errors to correct status code})

}

this is my understanding of an example of idiomatic use of Either

^^^^ literally the code we have in production

just like God intended 🙃 thanks everyone for clearing these subtleties up

imo, exceptions should be just that, exceptional

💯 this

Also,

Result

is really not great.

runCatching

catches

CancellationException

and breaks coroutines, and as the others have said it's untyped.

@CLOVIS interesting, I didn't know the subtlety that runCatching breaks coroutines... this team I'm about to join are all in on coroutines so I'd love to understand how in case you have a minute to explain?

If you have ten minutes to dive real deep: https://medium.com/better-programming/the-silent-killer-thats-crashing-your-coroutines-9171d1e8f79b 😄

CancellationException

is used internally by coroutines. If you don't know exactly what you're doing, you should not touch it (not catch it, not rethrow it…). Having a

catch(e: Exception)

or

catch(e: Throwable)

in your code can create memory leaks or break coroutines in other ways. Arrow (at least, the newer versions) also use

CancellationException

internally, and risk being broken too.

runCatching

has a

catch (e: Throwable)

, and should therefore not be used in coroutines.

Either.catch

is clever and doesn't have this problem (safe to use with coroutines).

intuitively I'd guess cancellationexception might have to do with eg scheduling and the internals of the state machine of coroutines and yeah that's probably something you don't want to catch but leave to the language to figure out what to do with haha

The very simplified explanation is that it's thrown by a child coroutine when its parent kills it. If you catch it, you risk having the child continue to work even though it shouldn't, have the parent no know the child has died…

@CLOVIS> Arrow (at least, the newer versions) also use CancellationException internally, and risk being broken too. Have you reported this? Seems like a pretty important thing to report before it makes its way out into users projects

Oh, it's a feature! It makes Arrow much better 🙂

wat 😅

@pakoito and @simon.vergauwen, who already commented in this thread and are both Arrow maintainers, can explain it better than I can. CancellationException is not a bad thing, what's bad is code that catches everything (and catches it accidentally). It's just a lower implementation detail that we shouldn't concern ourselves with, because it's complicated to use and it's easy to mess it up.

Short version: the only (safe) ways to exit from a code block are to throw an exception or to return. Arrow provides

effect

scopes that allow you to exit early without a return, hence exceptions are required for correct control flow. Any code that catches broad categories of throwables risks catching these control flow exceptions; this is an unavoidable trade-off of the functionality.

Deep down, it's always the same thing: don't catch broad categories of exceptions. It was already important in the Java days, and it's still important with Coroutines. But that's how Result works, so don't use it. (for the reason: Result is also more or less a technical detail of coroutines…)

@CLOVIS I'm a little confused, maybe I'm misunderstanding you... are you saying the fact Arrow doesn't catch these CancellationExceptions makes Arrow safe? Or are you saying that Arrow does use it internally and risks being broken? (because if Arrow risks being broken, I don't understand why you say it's a feature that makes Arrow better - Arrow being broken doesn't seem like a feature that makes it better 😅 )

If you yourself catch

CancellationException

without knowing exactly what you're doing, you can break Coroutines and Arrow. Coroutines and Arrow themselves are written by people who know what they are doing, and are very careful to use it correctly.

@CLOVIS ok, I was indeed misunderstanding you, thanks for clearing that up, I see what you were actually saying now

If you never catch

CancellationException

, you have nothing to worry about, yes.

IMO

NonFatal

should have been a part of Coroutines itself. It's great that Arrow makes it so easy though 🙂

right... but Arrow users themselves should rarely if ever find themselves writing their own code that calls nonFatal, nonFatalOrThrow etc, right? We should just use Arrow and let Arrow handle itself

If you don't write code that catches broad exception categories, you never need to use it, yes. If you do, that's the clever bit you need to use to avoid breaking everything (and Arrow needs to do it internally).

Got it, thanks. Side note, but it borderline brings me to tears how friggin amazing this community is. I remember the days of random IRC when you would jump into literally any channel and ask literally any question and the only replies you would get would be bullying, trolling, and every other type of toxic unhelpful bs. Likewise StackOverflow these days seem hell bent on closing every question because someone answered a similar but not the same question 20 years ago. Big, big thanks to everyone who contributes here, it's nothing short of amazing, can't thank you all enough.

Comments are not for extended discussion. This conversation has been moved to chat. :trollface:😒tackoverflow:

Btw I've been reading the article mentioned above, and it really is great. I'll save it somewhere.

sorry to revive this old thread but I was just curious if y'all have anything to say about this re writing code using runcatching and result

inside a coroutine, yeah you need to be careful if you are using the cancellation mechanism, but we're not really doing that. we're not generally launching our own coroutines. ktor provides us the coroutine per request, so we can easily operate within that. where we use run catching is to trap a database error for example.

I'm simply not familiar enough with it all to know if the above is fine or whether it could potentially result in the issues discussed in the thread (even then, arguably, the potential for issues is pretty small, no? especially if the machine isn't struggling, then there would be little reason for the parents/scheduler to kill children coroutines etc)

runCatching

, when used incorrectly (and if you're using it for error management, you are using it incorrectly) breaks coroutines and every other exception-based library. It doesn't matter if it's inside Ktor or anywhere else.

ok 😅 this is in the context of a new gig where runcatching is used in the fashion described I did raise it pointing out what has been said in this thread but the team seems unconcerned so not much else I can do (unlike my previous gig, arrow isn't used here, maybe in the future 🤷) really appreciate everyone's input and really sorry if I'm being repetetive asking about it again 🙂

Good luck with that… but if you are ever stuck trying to debug why a function is not called, or why a coroutine never terminates, or why it continues executing even through it's been cancelled: it's because of

runCatching

.