A Result type with no explicit custom state or error checkin

Question

A Result type with no explicit custom state or error checking it s helping me a lot in my projects with coroutines <https github com bloderxd result>

raulraja · Answer

Maybe not part of your design goals but ` get` is unsafe and there is history of folk complaining about methods like that being equivalent to null and NPEs A safe version would be `getOrElse` or simply a `fold` <https github com arrow kt arrow blob master modules core arrow core data src main kotlin arrow core Either kt L212 L221>

bloder · Answer

Thank you I m trying to get feedbacks about it and arrow seems to be a good library to get some tips and enhancements

alex.hart · Answer

Yeah I think `get` sort of defeats the purpose of a Monad Unwrapping data should be hard

bloder · Answer

it was made by this way because this is actually an struct with right value already defined as an Exception then basically the `catch` would be considered the `else` of `getOrElse` then if you have a `get ` inside of a `try` and it didn t throwed any kind of exception it would be considered a successful unwrapping of the `Result`

bloder · Answer

``` val value = try valueResult get catch e Exception Value ```

bloder · Answer

and with composing errors I can create a struct like that and handle errors with no impact in this `else` like ``` val value = try valueResult composeError handleNetworkProblems composeError handleSomeKindOfWrongValues get catch e Exception Value ```

Robert Jaros · Answer

How it compares to <https github com kittinunf Result>

bloder · Answer

I didn t see this solution deeply but reading the readme I don t see a good decoupled support to handle multiple error cases and that s what I m missing in result solutions a way to do that without the need of an error type checking and at the same time be an extensible solution and not a modified one we have the `Validation` solution in this case where if I understood correctly we set some results on it and this `Validation` struct is going to filter the errors or we can call `result failure ` that it s a simple callback to errors but in all these cases we need to do something like `when it is NetworkException gt handle network case is OtherException gt handle other case ` imagine that with a lot of error cases and sub error checking that s what I try to solve with this solution

bloder · Answer

a decoupled way to handle multiple and sub error cases and a good unwrapping way with no state checking because if the result value is an error it s going to throw an exception

bloder · Answer

then we can let this responsibility of checking the error when Result is built to unwrap the value easier ``` fun result n Int Result lt Int gt = if n lt = 3 Result error UnsupportedNumber composeError handleWrongNumber else Result ok n fun handleWrongNumber e UnsupportedNumber = println unsupported number result 2 get unsupported number result 5 get 5 ```