https://kotlinlang.org logo
#feed
Title
# feed
b

bloder

06/06/2019, 12:19 PM
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
r

raulraja

06/06/2019, 12:28 PM
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
👍 5
b

bloder

06/06/2019, 12:31 PM
Thank you, I'm trying to get feedbacks about it and arrow seems to be a good library to get some tips and enhancements
👍 1
a

alex.hart

06/06/2019, 12:44 PM
Yeah I think
get
sort of defeats the purpose of a Monad. Unwrapping data should be hard.
b

bloder

06/06/2019, 12:51 PM
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
Copy code
val value = try { valueResult().get() } catch(e: Exception) { Value() }
and with composing errors I can create a struct like that and handle errors with no impact in this
else
like:
Copy code
val value = try { valueResult().composeError(::handleNetworkProblems).composeError(::handleSomeKindOfWrongValues).get() } catch(e: Exception) { Value() }
r

Robert Jaros

06/06/2019, 3:06 PM
b

bloder

06/06/2019, 4:01 PM
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
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)
then we can let this responsibility of "checking" the error when Result is built to unwrap the value easier:
Copy code
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
11 Views