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

When is OnErrorThrowable created and received? #3347

Closed
mgp opened this issue Sep 16, 2015 · 3 comments
Closed

When is OnErrorThrowable created and received? #3347

mgp opened this issue Sep 16, 2015 · 3 comments
Labels

Comments

@mgp
Copy link

mgp commented Sep 16, 2015

From its Javadoc:

Represents a Throwable that an Observable might notify its subscribers of, but that then can be handled by an operator that is designed to recover from or react appropriately to such an error.

From this description I was thinking that operators like onErrorResumeNext might wrap emitted Throwables in an OnErrorThrowable instance using its from static factory method, and then pass that OnErrorThrowable instance to the global error handler. But the onError method of OperatorOnErrorResumeNextViaFunction looks like:

@Override
public void onError(Throwable e) {
    if (done) {
        Exceptions.throwIfFatal(e);
        return;
    }
    done = true;
    try {
        RxJavaPlugins.getInstance().getErrorHandler().handleError(e);

        ...

And so the "raw" Throwable is passed to the global error handler instead.

The problem we're trying to solve is this: the global error handler in our app forwards errors to Crashlytics. But we want to only forward Throwable instances that we're not already recovering from by methods like onErrorResumeNext. I was hoping that onErrorResumeNext would wrap such errors in OnErrorThrowable or something equivalent and our global error handler could only forward errors if they are not of this type.

Any thoughts on how we can achieve this behavior? Thanks!

@akarnokd akarnokd added Bug and removed Question labels Feb 9, 2016
@akarnokd
Copy link
Member

akarnokd commented Feb 9, 2016

Looks like that handler call is at the wrong place and belongs to after throwIfFatal. I'll post a PR for this.

@akarnokd
Copy link
Member

akarnokd commented Feb 9, 2016

See #3685

@akarnokd
Copy link
Member

Closing via #3689

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants