ApolloCall execute / toFlow / exception handling improvements #4003
Labels
✔️ Fixed in SNAPSHOTs
The fix has been merged and is available in SNAPSHOTs, and will be available in the next release
🚀 Type: Enhancement
⚠️ Breaking Change
To be done in next major version
Current situation
ApolloCall
exposes 2 APIs:suspend execute(): ApolloResponse
toFlow(): Flow<ApolloResponse>
execute()
will throw anApolloException
in case of a network, http, or cache error (can also beApolloCompositeException
in case of network and cache errors)It will also throw an exception if the underlying Flow contains more than 1 element (ex:
CacheAndNetwork
or with@defer
)Users need to handle 2 kinds of errors:
.errors
(With
ApolloResponse.dataAssertNoErrors
this can be centralized in one try catch)toFlow()
will throw an exception either as soon as it is encountered, or assembled inApolloCompositeException
after some responses have been emitted, depending on the case.Cache misses are either emitted with a null
data
or not emitted at all (configurable withemitCacheMisses
).Suggested change
exception: ApolloException?
field toApolloResponse
ApolloException
intoFlow()
: instead,ApolloResponse
are emitted with a nulldata
and non-nullexception
execute()
? Not sure of the most logical behavior to adopt withCacheFirst
and a cache miss + network error for instance. No exception thrown but return an ApolloResponse with a null data and anApolloCompositeException
inexception
?Benefits:
exception
orerrors
toFlow()
: cache misses / network errors can always be emitted, the caller can decide to ignore them or not by looking atexception
, depending on the needMore info
The text was updated successfully, but these errors were encountered: