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

OnErrorFailedException fix #3455

Merged
merged 1 commit into from
Oct 20, 2015
Merged

OnErrorFailedException fix #3455

merged 1 commit into from
Oct 20, 2015

Conversation

konmik
Copy link

@konmik konmik commented Oct 16, 2015

@@ -76,12 +76,7 @@ public static void throwIfFatal(Throwable t) {
if (t instanceof OnErrorNotImplementedException) {
throw (OnErrorNotImplementedException) t;
} else if (t instanceof OnErrorFailedException) {
Throwable cause = t.getCause();
if (cause instanceof RuntimeException) {
throw (RuntimeException) cause;
Copy link
Member

Choose a reason for hiding this comment

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

I guess by preventing the unwrapping, the error keeps propagating up, therefore, this change is essential. However, there could be code out there that depended on the original behavior (since Exceptions is part of the public API).

Copy link
Author

Choose a reason for hiding this comment

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

I don't think that there is such code. Such unwrapped exceptions were swallowed most of the time anyway.

Copy link
Member

Choose a reason for hiding this comment

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

Sounds reasonable.

Copy link
Member

Choose a reason for hiding this comment

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

Interesting bug. I agree that removing the unwrapping is needed.

@akarnokd
Copy link
Member

Looks good to me. 👍

@zsxwing
Copy link
Member

zsxwing commented Oct 18, 2015

Could you also fix the similar issues in Observable.subscribe and Observable.unsubscribe? Here are tests to reproduce them:

    @Test(expected = OnErrorFailedException.class)
    public void testOnErrorExceptionIsThrownFromSubscribe() {
        Observable.<Integer>create(s1 ->
                        Observable.<Integer>create(s2 -> {
                            throw new IllegalArgumentException("original exception");
                        }).subscribe(s1)
        ).subscribe(System.out::println, e -> {
            throw new RuntimeException();
        });
    }

    @Test(expected = OnErrorFailedException.class)
    public void testOnErrorExceptionIsThrownFromUnsafeSubscribe() {
        Observable.<Integer>create(s1 ->
                        Observable.<Integer>create(s2 -> {
                            throw new IllegalArgumentException("original exception");
                        }).unsafeSubscribe(s1)
        ).subscribe(System.out::println, e -> {
            throw new RuntimeException();
        });
    }

@konmik
Copy link
Author

konmik commented Oct 19, 2015

I would replace error handling in both of these methods with simple

    } catch (Throwable e) {
        Exceptions.throwIfFatal(e);
        try {
            subscriber.onError(hook.onSubscribeError(e));
        } catch (Throwable e2) {
            throw new OnErrorFailedException(e2);
        }
        return Subscriptions.unsubscribed();
    }

However, I think that the problem should be handled more generally.
The entire error handling policy should be reviewed and enforced.
Otherwise we will always see swallowed exceptions here and there.
Unfortunately, I don't have time right now to investigate the issue, I've just fixed what creates troubles for my current project.

@benjchristensen
Copy link
Member

Thanks for digging in to help with this. I thought we had squashed all of these swallowing of errors! Apparently not :-(

@benjchristensen
Copy link
Member

👍 Go ahead with this @akarnokd if you're still good with it.

@akarnokd
Copy link
Member

It is good as it is. Merging. The thing @zsxwing asked for can be done in a separate PR.

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