Is there any reason to adopt `kotlin.Result` if I’...

# stdlib

[Chris Fillmore]

Is there any reason to adopt kotlin.Result if I’m already using a custom Result type? This is my reasoning:

Pros of adopting `kotlin.Result`:
• De-duplication
• Don’t need to maintain my own type
• A portion of my code is essentially an SDK and it would be nice for its clients not to have to use my custom type, and could instead depend on Kotlin’s
• Better performance than my current type, since mine is not a value class (though it’s probably negligible in my use case)
Cons:
• My custom type is tailored somewhat, providing additional error detail data for e.g. analytics, so I would need to create a custom Exception to carry this information
• My custom Failure type doesn’t require an exception, and so can be used for other logical failures without an exception
• More development on kotlin.Result seems to be a no-go? (Per the KEEP https://github.com/Kotlin/KEEP/blob/master/proposals/stdlib/result.md#integration-into-the-language)
Anything I may not be considering? Also, any more detail on this:

We are working in other directions of making signalling error handling more pleasant to use in Kotlin.

[Chris Fillmore]

I know there are third-party libs with Result types with additional behaviour, but I’m not interested in adding a dependency

[dave08]

In the keep they give all their reasons for Result.

I used to use a custom one for more than just exceptions, bit I found that just returning sealed classes makes things much clearer. Exceptions need to be caught to be turned into some business logic return type and especially when there are multiple results to catch and aggregate. So I ended up only using Result for when there are real exceptions.

I guess this is a matter of taste, but I certainly wouldn't start converting everything to exceptions because they are more expensive to throw than just creating an object, and creating them to return them, is not so clear and hacky.

[gildor]

My custom Failure type doesn’t require an exception, and so can be used for other logical failures without an exception

It looks like a different case, I think the biggest reason for Result is to encapsulate exception as return type.
Result is not intended to replace all sealed/state classes which represent any kind result of operation

[Chris Fillmore]

Ok that makes sense, thank you for the feedback!

[ephemient]

I'd also be at least a little wary of using kotlin.Result - it's been marked as stable for use in user code, but as the compiler uses Result for its own purposes, there are occasions where it will generate bad output for your code, e.g. https://youtrack.jetbrains.com/issue/KT-45259 https://youtrack.jetbrains.com/issue/KT-47206 https://youtrack.jetbrains.com/issue/KT-50649

[gildor]

there are occasions where it will generate bad output for your code

It’s also true for other value/inline class, we catch quite a lot of those isseues, but we have no problems (at least on our project) with Kotlin 1.6

[ephemient]

the last issue I linked above still exists in Kotlin 1.6.10, but they're definitely all bugs that will be fixed. I'd just use Result and other inline classes sparingly in the meanwhile, so that you don't end up relying on any broken cases

[ephemient]

well, that's my opinion anyway. you may feel you'd rather use them widely and only back off after hitting a bug. if that works for you, that's fine too

[Chris Fillmore]

Thanks for the feedback. I will hold off on making changes since there's no real urgency for me

[Marc Knaup]

Same for me. I keep waiting for the first Kotlin release where I don’t find ClassCastExceptions related to value classes 😞