Retrofit Coroutine Exception Handling about baking-app-kotlin HOT 16 CLOSED

Agreed!

Previously we're using flow builder and after a while searching on the internet, then we're using the extension to reduce boilerplate, as stated in Kotlin Flow code it has same purpose:

Or using method references approach:

override fun doSomething(): Flow<Abc> = repository::doAbc.asFlow()

from baking-app-kotlin.

@mochadwi Yes it does handle exceptions. When using flow, you handle exceptions by using the catch operator which will catch exceptions that occur upstream. The catch operator doesn't handle exceptions for any operations added after it. For example, in the RecipeActionProcessor, you'll find this code:

private val refreshData: Flow<RecipeViewResult>
        get() = recipes.map { recipes ->
           ...
        }.onStart {
            emit(RefreshRecipesResult.Refreshing)
        }.catch { cause: Throwable ->
            emit(RefreshRecipesResult.Error(cause))
        }

Check out this article too for more context.
https://medium.com/@elizarov/exceptions-in-kotlin-flows-b59643c940fb

from baking-app-kotlin.

Closing this issue, because it already answered our usecase. Thanks a lot & much appreciate it once again @Ezike

from baking-app-kotlin.

Our backend usecase has a custom body response using http status code for 4xx & 5xx

E.g image:

from baking-app-kotlin.

Ah, I see. So the error catching was built-in when using Flow.

After reading your code, the .catch lambda exist on *ActionProcessor and returned with data class Error(val cause: Throwable) that explains everything!

from baking-app-kotlin.

In result, our code is much cleaner now without try-catch blocks!

from baking-app-kotlin.

Ah, I see. So the error catching was built-in when using Flow.

After reading your code, the .catch lambda exist on *ActionProcessor combined with data class Error(val cause: Throwable) that explains everything!

yea exactly

from baking-app-kotlin.

Thanks and really appreciate it!

from baking-app-kotlin.

In result, our code is much cleaner now without try-catch blocks!

Yea with flow you can use the catch operator, but with regular suspending functions, you still need to use a try / catch

from baking-app-kotlin.

In result, our code is much cleaner now without try-catch blocks!

Yea with flow you can use the catch operator, but with regular suspending functions, you still need to use a try / catch

Ah, I see. It's better to return a Flow (when using catch operator) instead of using suspend modifiers?

from baking-app-kotlin.

I've read in elizarov medium article and article that compare rx & coroutine here: http://disq.us/p/259lped

And my PoV was, like this:

fun returnListUseFlow(): Flow<List<Abc>>>

suspend fun returnSinglePojo(): Abc

@Ezike after you mention about suspend modifiers does that means, we have to use like this as well:

fun returnSinglePojo(): Flow<Abc>

CMIIW

from baking-app-kotlin.

In result, our code is much cleaner now without try-catch blocks!

Yea with flow you can use the catch operator, but with regular suspending functions, you still need to use a try / catch

Ah, I see. It's better to return a Flow (when using catch operator) instead of using suspend modifiers?

You can only use the catch operator with flow.
I guess if you're using mvi architecture you do need to wrap your suspending retrofit calls with flow

from baking-app-kotlin.

I've read in elizarov medium article and article that compare rx & coroutine here: http://disq.us/p/259lped

And my PoV was, like this:

fun returnListUseFlow(): Flow<List<Abc>>>

suspend fun returnSinglePojo(): Abc

@Ezike after you mention about suspend modifiers does that means, we have to use like this as well:

fun returnSinglePojo(): Flow<Abc>

CMIIW

If you're not wrapping your network call in a flow, you need to use try catch to handle exceptions. There's also a runCatching function that returns a result type that could either be a success or failure if you don't want to write try/catch blocks

from baking-app-kotlin.

There's also a runCatching function that returns a result type that could either be a success or failure if you don't want to write try/catch blocks

Awesome, noted will using runCatching for this usecases.

I guess if you're using mvi architecture you do need to wrap your suspending retrofit calls with flow
Ah, nice. We're using this extensions:

// extensions
fun <R> suspendAsFlow(block: suspend () -> R): Flow<R> = block.asFlow()

// repository
suspend fun doAbc(): Abc

// usecase
override fun doSomething(): Flow<Abc> = suspendAsFlow { repository.doAbc() } 

Or does flow already has extensions for transforming from suspend into Flow? @Ezike

from baking-app-kotlin.

Ah, nice. We're using this extensions:

// extensions
fun <R> suspendAsFlow(block: suspend () -> R): Flow<R> = block.asFlow()

// repository
suspend fun doAbc(): Abc

// usecase
override fun doSomething(): Flow<Abc> = suspendAsFlow { repository.doAbc() } 

Or does flow already has extensions for transforming from suspend into Flow? @Ezike

This is nice. You can also just use the flow builder and call your suspending function inside...

override fun doSomething(): Flow<Abc> = flow { emit(repository.doAbc()) }

from baking-app-kotlin.

Closing this issue, because it already answered our usecase. Thanks a lot & much appreciate it once again @Ezike

You're welcome

from baking-app-kotlin.