A Result type with no explicit custom state or err...

# feed

[bloder]

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]

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]

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]

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

[bloder]

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]

val value = try { valueResult().get() } catch(e: Exception) { Value() }

[bloder]

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]

How it compares to https://github.com/kittinunf/Result ?

[bloder]

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 ->{//handle network case} is OtherException -> {// 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]

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]

then we can let this responsibility of "checking" the error when Result is built to unwrap the value easier:

fun result(n: Int): Result<Int> = if(n <= 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