Hey, it would be nice if I could do result.getOrNull or result.getOrElse(null) or similar as sometimes nulls are used to show there is an error instead of an exception being thrown.

Kotlin 1.3 introduces a new built in type called Result<T> (docs) in the standard library (stdlib) and in the kotlin package.

Do you have an opinion on it? It seems to have taken a lot of inspiration from this library, but with one big difference: It doesn't have an equivalent to flatMap for operations that return a new Result<T>. It also doesn't place any constraints on errors, which are typed as Throwable.

The immediate inconvenience after upgrading my project to kotlin 1.3 is that I now need to explicitly add the import to use com.github.kittinunf.result.Result.

The KEEP can be seen here: https://github.com/Kotlin/KEEP/blob/master/proposals/stdlib/result.md

Description

This is to release the new version for Result v4.0.0.

• Thanks sooo much for all the effort made by @Globegitter #74, this indeed a great improvement on the library.

I've implemented doOnError method on Result which is very similar to RxJava doOnError operator.

Example usage:

val num = Result.of<Int, Exception> { "1a".toInt() }
            .doOnError { log.error { "Cannot parse value to Int" } }
            .get()

Whenever an unexpected exception gets thrown while evaluating a function with Result it leads to an unintuitive ClassCastException. Here is a simple example:

import com.github.kittinunf.result.Result
import org.junit.jupiter.api.Test
import kotlin.test.fail

internal class ResultExceptionClassCastTest {
    class MyException: Exception()

    @Test
    fun `Unexpected exception leads to unintuitive ClassCastException`() {
        Result.of<String, MyException> {
            operation("something")
        }.fold({}, {
            fail("Not reached")
        })
    }

    private fun operation(it: String): String {
        throw IllegalArgumentException()
        return "never reached $it"
    }
}

Is there something that I as a library user can do to handle this better? Is this an issue with the library?

The simple solution would be to expect an Exception (or Throwable!), and then to cast to the expected type, if it indeed is that type, but this doesn't seem like a very good solution.

Hi,

Firstly I would like to congratulate you for the awesome project!

I'm trying to use result-coroutines in my project, but Gradle cannot download the artifact. Any idea?

I have the following repositories:

repositories {
    google()
    jcenter()
    maven { url "http://kotlin.bintray.com/kotlinx" }
}

I'm new to Kotlin, so I may be missing something obvious, but it seems to me that Result values are constrained to Any rather than Any? because of <V : Any>.

I believe this means that I can't have a result of Result<String?, Exception>.

What should we do when null is a legal value?

I've been writing a JSON decoder combinator where Decoder<T> means that the decoder will return Result<T, Exception> when applied to a JSON string. Since JSON can contain nulls, I want to implement a null combinator such as Decoder.nullable(Decoder.string) which returns Result<String?, Exception>.

However, I wasn't sure how to make this work beyond bringing in some sort of Maybe<T> : Just<T> | None monad so that I could return Result<Maybe<String>, Exception>. I'd prefer to just use Kotlin's optional here since it already exists.

I just migrated from 2.2.0 to the current latest version (5.1.0) and the main diference I saw was the nullable success, which I found just great!

But, one thing that I didn't get was the signature change on the get() method. Given that Result.Success<V>'s V can now be a nullable type, why does the Result's abstract get() has to have an "enforced" nullable return (: V?).

This feels somewhat counter intuitive to me, given that, even if I have a non-nullable Result value (e.g.Result<String, Exception>), its get() will always return a nullable one (String?), which just includes an (apparently) unnecessary complexity to handle the return.

Is there a particular reason for this design? Perhaps some use case that I'm not seeing right now? If no, I would like to propose a change removing this enforced nullability on get()'s return type: https://github.com/kittinunf/Result/pull/91

This adds most of the methods and changes we have been using internally and we think really improves the usability of this library and fixes an imo very important bug we ran into a lot at the beginning in production and is not super easy to debug if you are not aware of it: #59

One nice thing about having all these inline methods it basically means that we do not need a separate coroutines result but that one can work out of the box with coroutines as you can see in the .map test I added.

I know this PR adds a lot at once, I am also happy to split it up and I guess it would require a 4.0 release. Let me know what you think @kittinunf .

Since Exception extends Throwable, I think the better way is to use Throwable over Exception for type and catching errors.

Kotlin Standard Library

Tweet

https://twitter.com/relizarov/status/1299248297849303040

From https://github.com/kittinunf/fuel/issues/805:

It'd be nice to able to do the following:

1. Transform List<Result<Foo, FuelError>> into Result<List<Foo>, FuelError>. If any of the Results is an error, the final Result is an error too, sort of an AND.
2. Transform List<Result<Foo, FuelError>> into Result<List<Foo>, FuelError>. If any of the Results is a success, the final Result is a success too, sort of an OR.

This is more a question. Probably somebody figured out how to tell to Android Studio that I'm using com.github.kittinunf.result.Result instead of the default one. There is no issue if I'm typing Result symbol by symbol - then I can just choose appropriate import. However, if I insert code from browser or other place (not AS), then AS always uses default Result. Is there a way to substitute it for all the cases by com.github.kittinunf.result.Result?