Don't crash when ExPlat API request failed

[wzieba]

Description

This PR wraps Call#execute in try/catch to make sure that SDK doesn't crash the app in case of API connection issues. Internal context: p1731543068879949-slack-C07J5LNP4SF

Testing

1. Cherry out fabe1d7 and assert that the newly added test throws unhandled UnknownHostException exception
2. Check out 138df3b, rerun test and see that exception is handled

[wzieba]

I've decided to go with a try/catch as this request is short-lived so I don't think we have to support graceful cancellation of this coroutine.

[MiSikora]

I'm not sure I follow. try/catch and runCatching behave similarly and don't interact with the suspension mechanism. The main difference is that try/catch allows selective exception handling, whereas runCatching catches all exceptions, including CancellationException, which must be re-thrown. However, these two blocks are functionally equivalent:

suspend fun foo(): String = TODO()

val value = try {
  foo()
} catch (e: Throwable) {
  if (e is CancellationException) throw e
  null
}

val value = runCatching { foo() }
  .getOrElse { e ->
    if (e is CancellationException) throw e
    null
  }

In our case, though, it doesn’t matter because we aren't calling any suspending functions. Call.execute(), JsonAdapter.fromJson(), and ResponseBody.source() are all blocking, and we don’t invoke yield(), so there's no opportunity for coroutine cancellation during execution. I think it is perfectly fine here. I'm only confused about the reason of graceful cancellation support as all calls are blocking.

[wzieba]

try/catch and runCatching behave similarly

I didn't mean runCatching. I rather meant suspendCancellableCoroutine idea you suggested on Slack.

so there's no opportunity for coroutine cancellation during execution.

In the current shape - yes. But if I introduced suspendCancellableCoroutine, it'd look similar to

 suspendCancellableCoroutine { continuation ->
            val call = okHttpClient.newCall(request)
            continuation.invokeOnCancellation { call.cancel() }

            call.enqueue(object : Callback {

which would be cancellable.

[MiSikora]

Right, I didn't get that from the message. Thanks for clarifying.