I'm writing my first coroutine in a production app! It's an Android app that is using Retrofit with coroutines.

viewModelScope.launch {
                val userProfileResponse = apiManager.client!!.getProfile()
                if (userProfileResponse.isSuccessful) {
                    _viewState.value = _viewState.value?.copy(isLoading = false, profile = userProfileResponse.body())
                } else {
                    Log.e(TAG, "Not success")
                }
        }

and it works! BUT I tried to run the app in airplane mode and it crashes. If I use a try catch it won't crash, but I'm confused by why the IDE doesn't force me to have a try/catch. Does anyone know why?

because it's not required by the language?

I could have sworn that plain old synchronous Retrofit forces you to do a try/catch and if I didn't know about it, then I probably would have been scratching my head here. Are you saying that kotlin doesn't enforce try/catch blocks? If so... I guess I should go to #getting-started because I didn't know that.

yea, there are no checked exceptions in kotlin

👀 I had no idea. 🤯

@octylFractal thanks. One last question I suppose. Is there anything that helps me know which Exceptions I should catch though? Like what exceptions could the retrofit method throw? Right now I just have a general

e: Exception

that I'm catching, but I'm sure there's multiple different network error exceptions?

in general look at the documentation, if it's not documented then it's much more difficult.

Thanks. I wasn't able to find anything in the readme or the github page for Retrofit + coroutines so I'll keep digging in the java docs.

This is very specific crash which is fixed

This is very specific crash which is fixed

You're talking about the crash in the blog post? Not my crash... right?

Yes

I don't know if I should use Response. I actually just tweeted that at @jw I don't really know what I'm doing, but a Response type allows me to access the response code (200 or other) and I can also access response.errorBody() which is nice because my backend team sends me a completely different error body than the Type that typically comes back from the call. So basically, I use Response for error handling.

If you need error body, you can get it from HttpException:

try {
  getProfile()
} catch (e: HttpException) {
  e.response().errorBody()
}

Interesting. I didn't know this. Still not sure what the best thing to return is. I do feel like having the Response is convenient...

It's error prone approach (especially when you do not use result, for example when body is null), because you have to check for success manually