After a few years of Kotlin, I recently ran into what I consider to be some shortcomings here as well, with respect to returning errors. As we know, Kotlin does not have checked exceptions. Ok, but ...

The KEEP for Result<T> goes into details, but basically there are a few ways of handling return values + errors:

1) throw exception if something goes wrong

2) return null if something goes wrong (stdlib XXXorNull)

3) Use Result<T> in some cases, its error type is not paramerized and catches CancellationException

4) Use Arrow if Result<T> doesn't meet your needs

5) Return Sealed Classes / Interfaces with all the possibilities.

Right now, I am going the Sealed Class interface route, but its such a verbose pain in the ass, so I only use it at certain levels of abstraction (like from a Repository, or library API, etc).

The code I needed to write was calling into okio, and it was not straightforward to figure out what kinds of exceptions would be thrown by the JVM layer underneath (docs just say IOException, but sublasses can be thrown).

Its sad to see they still haven't figured this out. Rich Errors was mentioned a year ago but its not even in preview yet. Its also not clear how it will work with Java interop.