Handling network call errors in Kotlin

When designing how to handle network calls in your app, you might think that you are done as soon as you define your interface. You are halfway there: you have defined the "happy" path. But what happens when not everything goes according to plan? That's the other half.

As always, a reminder that there are no completely right or wrong answers here. It's rather a matter of choosing the most suitable approach depending on your requirements and your app architecture to make your life easier in the long run.

The straightforward way: try-catch statements

An error is by definition an exception to the normal flow of the app. Kotlin supports exception throwing and catching quite smoothly. So, all you have to do is throw the correct exception when an issue arises from the network library.

To make your code network library independent, a good approach is to create your own BaseNetworkException class and create an exception class for each type of error that can happen.

viewModelScope.launch {
    try {
        callService()
    }
    catch (e: NoNetworkException) {
        // Handle it
    }
    catch (e: AuthenticationNetworkException) {
        // Handle it
    }
}

The downside here is that you need to wrap every network call with a try-catch statement. If you forgot about it and an error occurs, your app will crash.

The modern way: return Result

A network call can either succeed or fail. So a Result class should represent exactly this: a success state with the data, or a failed state with the exception.

Kotlin has a built-in Result but when trying to use it as a return type you will get kotlin.Result' cannot be used as a return type (why). You can either create your own Result class, use an open-source alternative, or use a hack to use the standard library Result (not really recommended since it can break your build in the future).

viewModelScope.launch {
    callService().fold(
        { data ->
            // Successful call
        }, 
        { error ->
            when (error) {
                is NoNetworkException -> // Hanlde it
                is AuthenticationNetworkException) -> // Hanlde it
            }
        }
}

Using this approach you are forced to handle the potential error. The downside might be that it gets repetitive, especially if handling the same generic errors (but this can be fixed by using common handler methods).

The coroutine way: CoroutineExceptionHandler

The launch coroutine builder accepts a default exception handler parameter. The handler is activated only within the scope of the coroutine. This could be convenient for handling all the "common" exceptions (e.g. no internet connection). With this approach, there's no need to repeat how to handle common errors.

Any errors not handled by the coroutine exception handler will still have to be handled by one of the previous ways (or create specific CoroutineExceptionHandler instances).

val genericErrorHandler = CoroutineExceptionHandler { _, error ->
    when (error) {
        is NoNetworkException -> // Hanlde it
        is AuthenticationNetworkException) -> // Hanlde it
    }
}

[...]

viewModelScope.launch(genericErrorHandler) {
    callService()
}

Hopefully, by now you have a bit clearer picture on how to handle your network errors. Happy coding!