takahirom
01/28/2022, 1:33 AMsuspend fun fetch(): List<Item>
2. The advantage of using Result is that you can specify the type of error and ensure that the API user can handle it.
suspend fun fetch(): Result<List<Item>, FetchError>
In the architecture guide, there is a statement that you should use Kotlin's error mechanism. Is it to take advantage of this?
For coroutines and flows, you should use Kotlin's built-in error-handling mechanism.https://developer.android.com/jetpack/guide/data-layer?hl=en#expose-errors
Orhan Tozan
01/28/2022, 7:25 PMtakahirom
01/29/2022, 2:20 AMThis is necessary for reactive programming APIs that don't have proper exception handling, such as LiveData.Because of the above statement, I had interpreted that if there is no error mechanism such as LiveData, I should use Result, and if there is an error mechanism such as coroutines, I should use that mechanism.
Orhan Tozan
01/29/2022, 9:53 AMAdam Powell
01/29/2022, 4:17 PMResult<T>
that's either a wrapped result or a Throwable outside of infrastructure code that pipes a runCatching
result into a Continuation.resumeWith
or something like that, to redirect the result to another call stack more appropriate for handling it. More domain-specific error states emitted via a LiveData or StateFlow can be more appropriate in context, but kotlin.Result
is the result of a specific operation in time and it doesn't make a very good state object..firstOrNull(): R?
type API shapes handle the cases where the caller is in a position to make a decision on how to proceed if the operation can't complete its requested purpose; a stack trace and debugging message is overkillfinally
blocks clean up as necessary, but often when you're deep enough in a call stack where an error happens, you're not in a position to do something intelligent about it until several layers up. Asking your callers to write multiple layers of manual error propagation is kind of silly. That's what exceptions are for.suspend
in the picture, finally
is even more powerful as a resource cleanup mechanism.gildor
01/31/2022, 5:05 AMRust’s result type and the language support for it are considered quite goodIt considered by some as good, but honestly I didn’t find it very good in terms of how easy to use it. It’s safe out of the box, it’s true, but because it’s very hard to combine multiple error types safely, imagine you have a function which does network request, save it to database and do some internal validation, if you want to propagate all those errors you need a custom Result type with all the cases combined and also resulting code doesn’t look very well, you sometimes even need intermediate result types just for you own code to propagate results in a type safe way I understand why it was done this way, and I like idea itself, I just found that it quite tedious to work in this style, and this is the reason why so many Rust code which I see just doing .unwrap() + Result block with generic Error type This why things like
anyhow
library exist to wrap any error
I think it’s completely solvable with better API for errors, but at least what I see there is no simple way to do this using std lib
I have very limited experience with Rust, maybe I just was not went deep enough and there are better approachestakahirom
02/28/2022, 6:32 AM