3 ms·

> - Ban exception propagation altogether: in Kotlin, wrap the computation in 'runCatching' to get a Result<T>; or in Java, use result4j [1] which provides simil

> - Ban exception propagation altogether: in Kotlin, wrap the computation in 'runCatching' to get a Result<T>; or in Java, use result4j [1] which provides similar functionality. ‘runCatching’ was never intended for user code. It was made for internal use in coroutines machinery and when community complained they made it public. But it is still a half-baked API that is better to avoid (catching CancellationException, doesn’t compose well in general). The whole runCatching/billions of Result<T> copies are worse than Go’s “if err !=“. Unless JetBrains rolls out language support for something like Rust’s Result, exceptions are superior and Kotlin community would better off embracing them instead of trying to be different for the sake of being different. https://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/share/doc/rust/html/std/result/index.html#the-question-mark-operator- https://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/sh...

rileymichael 3y ago
I have a hard time agreeing that exceptions (as they exist in kotlin, unchecked) are superior. There is no way to communicate (outside of docs) to callers that a function is possibly unsafe and that they should handle it. Good callout on the stdlib `Result`, a lot of people aren't aware of the `CancellationException` issue. Another pain point is that the error is constrained to `Throwable`, which is rather obtuse for general business logic (and you're likely generating stack traces needlessly unless you disable `writableStackTrace` on your custom throwables). I'm a fan of https://github.com/michaelbull/kotlin-result https://github.com/michaelbull/kotlin-result which has a fantastic API and supports monad comprehension which helps avoid the "arrowheads" from not having a built in operator.
- vips7L 3y ago
  That result library doesn’t look thread safe at all. I would be extremely cautious using it.
  - michaelbull 3y ago
    Author here. I have no idea what you could possibly mean with this comment. The coroutineBinding implementation correctly uses the coroutines API for parallel decomposition of Result bindings, exactly how the Kotlin Coroutines guide tells you to, backed by a Mutex[1]. The coroutineBinding isn't even the main selling point of the library, you can use it without using this feature entirely. Please could you elaborate on what "looking thread safe" means to you? The only portion of the library that supports concurrency *is* thread safe - the unit tests[2] prove it and the use of concurrency primitives such as Kotlin's Mutex[3] are indicative of this. I truly have no idea how you've judged the entirely of the library on whether it's "thread safe" when there is a single function (in an extension library, not the core one) that's related to concurrency and it is very clearly using concurrency primitives as intended. With regards to "being cautious using it", you don't need to be. The maven central statistics suggest its being downloaded 300,000 times per month. If there was something wrong with it, it's likely somebody would have raised this already given how frequently the project has been adopted over the last seven years. [1] https://github.com/michaelbull/kotlin-result/blob/master/kotlin-result-coroutines/src/commonMain/kotlin/com/github/michaelbull/result/coroutines/CoroutineBinding.kt#L73 https://github.com/michaelbull/kotlin-result/blob/master/kot... [2] https://github.com/michaelbull/kotlin-result/blob/master/kotlin-result-coroutines/src/commonTest/kotlin/com.github.michaelbull.result.coroutines/AsyncCoroutineBindingTest.kt https://github.com/michaelbull/kotlin-result/blob/master/kot... [3] https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.sync/-mutex/ https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-corout...
michaelbull 3y ago
> Unless JetBrains rolls out language support for something like Rust’s Result, exceptions are superior and Kotlin community would better off embracing them instead of trying to be different for the sake of being different. If this was true, why do Jetbrains themselves keep reinventing their own per-domain Result classes for their new code? For example, in their coroutines library they invented another Result type specifically for Channels[1] and isn't interoperable at all with their other Result type[2] that was also originally written to facilitate some of the coroutines code. If Jetbrains' own internal library authors keep reaching for a Result type then I think we're better off following suit, because if they thought exceptions were superior in this example, they would have used them. [1] https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.channels/-channel-result/ https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-corout... [2] https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-result/ https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-result/

rileymichael 3y ago

I have a hard time agreeing that exceptions (as they exist in kotlin, unchecked) are superior. There is no way to communicate (outside of docs) to callers that a function is possibly unsafe and that they should handle it. Good callout on the stdlib `Result`, a lot of people aren't aware of the `CancellationException` issue. Another pain point is that the error is constrained to `Throwable`, which is rather obtuse for general business logic (and you're likely generating stack traces needlessly unless you disable `writableStackTrace` on your custom throwables). I'm a fan of https://github.com/michaelbull/kotlin-result https://github.com/michaelbull/kotlin-result which has a fantastic API and supports monad comprehension which helps avoid the "arrowheads" from not having a built in operator.

vips7L 3y ago
That result library doesn’t look thread safe at all. I would be extremely cautious using it.
- michaelbull 3y ago
  Author here. I have no idea what you could possibly mean with this comment. The coroutineBinding implementation correctly uses the coroutines API for parallel decomposition of Result bindings, exactly how the Kotlin Coroutines guide tells you to, backed by a Mutex[1]. The coroutineBinding isn't even the main selling point of the library, you can use it without using this feature entirely. Please could you elaborate on what "looking thread safe" means to you? The only portion of the library that supports concurrency *is* thread safe - the unit tests[2] prove it and the use of concurrency primitives such as Kotlin's Mutex[3] are indicative of this. I truly have no idea how you've judged the entirely of the library on whether it's "thread safe" when there is a single function (in an extension library, not the core one) that's related to concurrency and it is very clearly using concurrency primitives as intended. With regards to "being cautious using it", you don't need to be. The maven central statistics suggest its being downloaded 300,000 times per month. If there was something wrong with it, it's likely somebody would have raised this already given how frequently the project has been adopted over the last seven years. [1] https://github.com/michaelbull/kotlin-result/blob/master/kotlin-result-coroutines/src/commonMain/kotlin/com/github/michaelbull/result/coroutines/CoroutineBinding.kt#L73 https://github.com/michaelbull/kotlin-result/blob/master/kot... [2] https://github.com/michaelbull/kotlin-result/blob/master/kotlin-result-coroutines/src/commonTest/kotlin/com.github.michaelbull.result.coroutines/AsyncCoroutineBindingTest.kt https://github.com/michaelbull/kotlin-result/blob/master/kot... [3] https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.sync/-mutex/ https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-corout...

michaelbull 3y ago

> Unless JetBrains rolls out language support for something like Rust’s Result, exceptions are superior and Kotlin community would better off embracing them instead of trying to be different for the sake of being different. If this was true, why do Jetbrains themselves keep reinventing their own per-domain Result classes for their new code? For example, in their coroutines library they invented another Result type specifically for Channels[1] and isn't interoperable at all with their other Result type[2] that was also originally written to facilitate some of the coroutines code. If Jetbrains' own internal library authors keep reaching for a Result type then I think we're better off following suit, because if they thought exceptions were superior in this example, they would have used them. [1] https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.channels/-channel-result/ https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-corout... [2] https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-result/ https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-result/