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

Exception rethrown inconsistently with/without .flatMap() in 0.16.1 #771

Closed
jayessdeesea opened this issue Jan 21, 2014 · 7 comments
Closed

Comments

@jayessdeesea
Copy link

Maybe I just don't understand JavaRX yet but this seems inconsistent.

Run this, and then re-run without the .flatMap(). Note that the second run passes the unit test.

@Test(expected = RuntimeException.class)
public void verifyExceptionIsThrownIfThereIsNoExceptionHandler() {

    Observable.OnSubscribeFunc < Object > creator = new Observable.OnSubscribeFunc < Object >() {

        @Override
        public Subscription onSubscribe(Observer < ? super Object > observer) {

            observer.onNext("a");
            observer.onNext("b");
            observer.onNext("c");
            observer.onCompleted();

            return Subscriptions.empty();
        }
    };

    Func1 < Object, Observable < Object >> manyMapper = new Func1 < Object, Observable < Object >>() {

        @Override
        public Observable < Object > call(Object object) {

            return Observable.from(object);
        }
    };

    Func1 < Object, Object > mapper = new Func1 < Object, Object >() {

        private int count = 0;

        @Override
        public Object call(Object object) {

            ++count;

            if (count > 2) {
                throw new RuntimeException();
            }
            return object;
        }
    };

    Action1 < Object > onNext = new Action1 < Object >() {

        @Override
        public void call(Object object) {
            System.out.println(object.toString());
        }
    };
    Observable.create(creator).flatMap(manyMapper).map(mapper).subscribe(onNext);
}
@zsxwing
Copy link
Member

zsxwing commented Jan 22, 2014

The problem here is that one of SafeObserver.onError is called twice: one is RuntimeException, the other is OnErrorNotImplementedException. A little to similar to #748

@zsxwing
Copy link
Member

zsxwing commented Jan 23, 2014

Not sure this is a bug. If an Observer throws an Exception in onError, what will happen? I think Rx does not guarantee that it always calls onError when an exception is thrown. It only guarantees that it at least calls onError once even if there are many exceptions. Do I misunderstand anything?

@jayessdeesea
Copy link
Author

the behavior is inconsistent. that's the bug.

Document that the throwables are silently swallowed or thrown if there is no onError()

Errors should probably always be thrown because I want my JVM to terminate before my JVM starts misbehaving and serving wrong data

@benjchristensen
Copy link
Member

If an onError is not implemented it should always be thrown.

@zsxwing
Copy link
Member

zsxwing commented Jan 28, 2014

@benjchristensen , Looks some operators do not handle OnErrorNotImplementedException correctly. Could you propose a guild about how to handle exception in RxJava? Now we have RuntimeException except OnErrorNotImplementedException, Exception, Error and OnErrorNotImplementedException.

@benjchristensen
Copy link
Member

Dealing with in pull request #839

benjchristensen added a commit to benjchristensen/RxJava that referenced this issue Feb 8, 2014
- ReactiveX#748 (comment)
- ReactiveX#771
- ReactiveX#789

- SynchronizedObserver is for synchronization, not error handling or contract enforcements, that's the job of SafeSubscriber
- Removed some unit tests that were asserting unsubscribe behavior that relied on SynchronizedObserver. They were testing something they are not responsible for.
@benjchristensen
Copy link
Member

Should be fixed in #839

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

No branches or pull requests

3 participants