Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce ApolloExceptions #379

Merged
merged 4 commits into from
Apr 1, 2017

Conversation

sav007
Copy link
Contributor

@sav007 sav007 commented Mar 31, 2017

Closes #367

Introduces 4 ApolloExceptions:

  • ApolloException generic any runtime errors should be wrapped into it
  • ApolloHttpException if http status code != 200
  • ApolloNetworkException any network, timeouts etc.
  • ApolloParseException response parse errors

See new API:
https://github.com/apollographql/apollo-android/pull/379/files#diff-18999fee7e5f70c2f862624cbab6d833
https://github.com/apollographql/apollo-android/pull/379/files#diff-b059ebbc703ddbbde44ba44eed598837

@mandrizzle


@Nonnull ApolloPrefetch enqueue(@Nullable Callback callback);

ApolloPrefetch clone();

void cancel();

interface Callback {
void onSuccess();
abstract class Callback {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, like the option to use a single callback and inheritance, or the split methods.


public abstract void onFailure(@Nonnull ApolloException e);

public void onHttpError(@Nonnull ApolloHttpException e) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be nice to pass in the status code and response here, making this look like:

public void onNetworkError(int status, Response response, @Nonnull ApolloNetworkException e)

I fell it is nice not having to dig through the exception, secondly, it makes it clearer what we have to work with

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure about this, as it becomes too clumsy to have 3 params to handle one error.
And if user really decides to handle network error then don't see any issue to dig into ApolloNetworkException to extract what he needs.

public abstract void onFailure(@Nonnull ApolloException e);

public void onHttpError(@Nonnull ApolloHttpException e) {
onFailure(e);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thoughts on calling closeQuietly(e.response()) after we call onFailure? I think it would prevent a lot of leaked connections

onFailure(e);
}

public void onNetworkError(@Nonnull ApolloNetworkException e) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we have the exception ApolloNetworkException? I think an IOException is more fitting for this case

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We decided to wrap with ApolloNetworkException that extends ApolloException.
So from our sync API call (com.apollographql.apollo.ApolloCall#execute) user should expect only one type of errors ApolloException.

@sav007 sav007 merged commit f1bea2a into apollographql:master Apr 1, 2017
@sav007 sav007 deleted the feature-367/apollo-exception branch April 1, 2017 00:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants