apollo-kotlin: Deprecate ApolloCompositeException with Error level and use suppressed exceptions instead

Use case I’m finding ApolloCompositeException annoying to handle. It contains multiple exceptions and you kind of have to pick one exception, and based on it show error message to user. Along side that, you have to potentially handle and report all other errors (e.g. Firebase).

For example:

try {
    graphqlService.mutate(Whatever())
} catch(e: ApolloCompositeException) {
    when (val causes = e.suppressedExceptions) {
        causes.any { it is ApolloNetworkException } -> TODO("handle network")
        causes.any { it is HttpCacheMissException } -> TODO("handle cache")
        else -> TODO("handle other")
    }
}

Describe the solution you’d like I may be missing some context, why it was designed in such a manner. But ideally, I would prefer smth like:

try {
    graphqlService.mutate(Whatever())
} catch(e: Exception) {
    when (e) {
        is ApolloNetworkException -> TODO("handle network")
        is HttpCacheMissException -> TODO("handle cache")
        else -> TODO("handle other")
    }
}

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 16 (16 by maintainers)

Most upvoted comments

Maybe we deprecate ApolloCompositeException with Error level?

Totally 👍

We could make a “error handling” release that simplifies the error handling a bunch

Agreed as well

Changing the type of exception thrown would require clients who handle it to update the catch accordingly so I guess that’s why I assumed we “can’t” really do it 😅.

Maybe we deprecate ApolloCompositeException with Error level? This way the symbol is still there (no ABI breaking change) but it forces all callers to update explicitely? My favorite timing to do this would be at the same time as reworking the way we “throw” in general (see https://github.com/apollographql/apollo-kotlin/issues/4003). We could make a “error handling” release that simplifies the error handling a bunch