re Result type It wasn t that it didn t open jus

Question

< elizarov> re Result type It wasn t that it didn t open just that I expected some sort of Algebraic data type sealed class hierarchy

elizarov · Answer

That particular proposal was specifically designed in encapsulated fashion so that implementation details are not public and can be optimized For application where efficiency is not of a paramount importance you can always roll your own sealed class it just takes a few lines of code

natpryce · Answer

I d want a Result type not to have a get method that throws Also I d want Result to be parameterised by the error type so that I can type check error handling conversion at the boundaries of bounded contexts So the error might be an exception or an enum or an instance of a sealed class hierarchy

elizarov · Answer

Parametrization by the error type is definitely out of the scope of Kotlin stdlib because that flies contrary to the conceptual approach to exceptions in Kotlin and there is no place it can be used by stdlib itself or other Kotlin related libraries Kotlin stdlib uses nullable types for that purpose If you want a type that represents either a result or some application specific kind of error then I d suggest using some kind of `Either` type for that It is easy to roll your own with a sealed class

elizarov · Answer

The name `Result` is specifically reserved to represent result of execution of a Kotlin function which is by definition of Kotlin language is either a declared result of the corresponding function or a `Throwable` E g in Kotlin a result of function declared with `fun X T` is actually `Either lt Throwable T gt ` and code blocks in Kotlin correspond to do notation on the corresponding monad

natpryce · Answer

But this is an alternative to exceptions to support type safety and so should not be limited by how kotlin implements exceptions

natpryce · Answer

If Result doesn t type check the error cases what s the point of it One might as well just use return values and exceptions

dmcg · Answer

A good discussion I wonder if it can be had more publicly Arguing that we can roll our own Either type doesn t help interoperability at all which was where I started Maybe if the stdlib needs this for its own purposes there is a need for both this Result and another ADT I m wary of an approach that requires me to create an exception an expensive process if one hasn t naturally occurred just to signal failure from a function

elizarov · Answer

The point of `Result` is described in the corresponding issue <https youtrack jetbrains com issue KT 18608>

elizarov · Answer

You should NOT use exeptions to signal an error condition that should be handled by direct invokers of the function This is bad style in Kotlin Exceptions in Kotlin are designed for errors that are handled at a larger scope For local error conditions you should consider using nullable types for example when you are trying to find something and you need an indication that it wasn t found or domain specific sealed classes when you particular domain calls for a variety of error condtitions that need different ways ti handle them

natpryce · Answer

Exactly So the get method of Result should never throw

natpryce · Answer

Either it should not exist

natpryce · Answer

Or Result should be parameterised by both value type and error type and then get can be be defined for Result lt T T gt

dmcg · Answer

If we use domain specific sealed classes then there is no standard way to map over a series of operations from different providers That s why we re asking for stdlib sealed classes and are surprised to see the proposed Result type isn t them

natpryce · Answer

I ve put my implementation up on GitHub <https github com npryce result4k>

natpryce · Answer

And maven central

natpryce · Answer

For those who are interested

dave · Answer

Thanks < natpryce> although i for one am really hoping that something like this will make it s way into the Stdlib We don t want to recreate the Scala problem where there are many versions of the same simple concept knocking about and everyone is relying on different incompatible versions that s just bad for everyone

dmcg · Answer

The implementation meets my expectations But the name

yoavst · Answer

natpryce · Answer

I think the error side needn t be constrained to be a type of Exception

natpryce · Answer

< dmcg> what s up with the name Would you prefer a name that is a K based pun