What library would you recommend for checked excep...

# getting-started

[Mihai Voicescu]

What library would you recommend for checked exceptions?

https://arrow-kt.io/docs/apidocs/arrow-core/arrow.core/-either/
or
https://github.com/michaelbull/kotlin-result
(or maybe others)

[Vampire]

What's wrong with the stdlib Result class? https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-result/

[Mihai Voicescu]

As far as I can tell you can't define the exceptions in the stdlib version. Kinda like:

fun foo(): Result<Unit, Foo>

[Joffrey]

I also wonder what exactly you're trying to achieve. Usually creating your own domain-specific sealed class is so cheap that I don't get what you would expect from a library here

[Mihai Voicescu]

Was thinking it would be nice to clearly mark which is the successful option and have a consistent interface to extract it, similar to the Result of Rust.

kotlin-result seems to be very similar, but the fact that it's name collides with the std make it very annoying to use.

Was also curios what was the usual way to handle this cases in Kotlin.

[Vampire]

As there are no checked exceptions in Kotlin, no.
You just give the normal result type like fun foo(): Result<Unit>.
What is the reason you need to specify the type?

[Joffrey]

The way I see this in Kotlin is 3 possibilities:
• if failure is not expected (apart in case of programmer error), rely on unchecked exceptions
• if failure is expected but you don't really control which type of excpetions you're going to get, you can use Kotlin's Result from stdlib (e.g. with runCatching ), which allows to access the specific exception instance after the fact if needed
• if failure is expected and controlled (or at least used meaningfully), you can defined your own sealed class to represent different type of errors

[Alexander Levin]

I would say that both options seems fine:
• Arrow is a bit more popular and contains a bit more stuff even in core module.
• kotlin-result seems to be very small in scope (which is actually kinda cool) and also documentation is looking pretty good overall
Feature-wise (looking specifically for Either/Result) they look pretty similar: quite a lot utility functions, both have monad comprehension blocks etc. One thing that I can see - kotlin-result has more feature for integrating into kotlin-coroutines. Also there is ready to use example for ktor which is pretty cool.


I guess I would pick kotlin-result if I am only interested in Either/Result or Arrow (specifically core module in that case) if there is another thing that I would use from library.


That being said, neither option is really popular, looks like mostly sealed types are implemented from scratch (or checked error types are just not present in the code). May be wrong though.

[Mihai Voicescu]

Thank you all for your responses. I will go with the kotlin-result version (which still needs the Error types to be defined as a sealed class)

[Nick]

For kotlin-result, did anyone find a way to deal with the package name collision with the std Result ?

[Mihai Voicescu]

I used a type alias