# State of Kotlin.Result vs. kotlin-result?

**URL:** <https://discuss.kotlinlang.org/t/state-of-kotlin-result-vs-kotlin-result/21103>\
**Category:** Language Design\
**Created:** [March 6, 2021, 7:54am UTC](https://discuss.kotlinlang.org/t/state-of-kotlin-result-vs-kotlin-result/21103 "2021-03-06T07:54:45Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![Ilmir.Usmanov](https://avatars.discourse-cdn.com/v4/letter/i/e495f1/32.png) [@Ilmir.Usmanov](https://discuss.kotlinlang.org/u/Ilmir.Usmanov)\
**Post date:** [March 12, 2021, 12:02pm UTC](https://discuss.kotlinlang.org/t/state-of-kotlin-result-vs-kotlin-result/21103/4 "2021-03-12T12:02:52Z")

</div>

TL;DR: `kotlin.Result` is half-baked and is likely to change in the future.

A little bit of history - `kotlin.Result` was introduced in 1.3 as an internal class first, as it was intended to be used by compiler generated code only - namely coroutines. However, it was during testing process made public, since programmers saw the usefulness of the class as a Try monad and some of our users, particularly, arrow project, wanted to replace their own implementations of Try monad with the standard one.

Despite being forbidden by default, return `kotlin.Result` from a function is fully supported in the compiler and we try not to break the code, which returns `kotlin.Result`.

The reasons why it is forbidden by default are two-fold.

First, we might want to treat `kotlin.Result` similar to nullable types. I.e. possibly add a new syntax, for instance, ceylonesque `T | IllegalStateException`. Additionally, we might want to extend `?.` and `?:` to support that kind of types. Similar to nullables, `?.` is to retrieve value, and part after `?:` is executed if there is an exception, wrapped in the result.

Second, Kotlin does not support checked exceptions of any kind. However, some exceptions, like `FileNotFoundException` are checked in Java for a reason, and not catching the exception is an error. Returning result class enforces a user to check the value. So, it can be viewed as a replacement for checked exception. In that case, it is logical to compile functions, returning `kotlin.Result` as functions, returning value type and throwing the exception, so, when the user calls the function from Java, it is seen as a function, throwing checked exception, and thus, the user has to catch it.

Because of these two design issues, we do not encourage use of `kotlin.Result` as a return type - because sometime in the future there can be a breaking change of some kind. However, since we see the need for checked exceptions and Try monad, we do support it.

---

_[View the full topic](https://discuss.kotlinlang.org/t/state-of-kotlin-result-vs-kotlin-result/21103)._