-
Notifications
You must be signed in to change notification settings - Fork 7.6k
Take Operator Error Handling #217
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
Comments
@johngmyers can you take a look at this please since you have been involved in this code? |
See #216 for a discussion related to this. |
In the supplied unit test, the take operator has already delivered three So in my opinion it's an invalid test. Note that none of the trusted operators handle asynchronous |
For an amusing test, replace the |
Let me amend that statement. The test was bug-dependent: it depended on the very bug that was fixed in order to pass. Furthermore, if the test had applied |
Operators must work on both synchronous and asynchronous sequences, including error handling, and I understand that this issue exists on all kinds of operators. This issue is to demonstrate that there are challenging implementation details and nuanced behavior even when an operator implementation "looks correct". The discussion at #216 will carry this forward ...
With Whether this gets fixed in the operator or part of #216 is an open question. I think it should be done outside of the operator because too much error-prone boilerplate will need to exist in every single operator to try and get every use case handled. I'll hold this issue open until #216 is finalized but theoretically no code changes should be needed for the |
I just tested the unit test above and it works.
for @Test
public void testTakeWithErrorInObserver() {
final AtomicInteger count = new AtomicInteger();
final AtomicReference<Throwable> error = new AtomicReference<Throwable>();
Observable.from("1", "2", "three", "4").take(3).subscribe(new Observer<String>() {
@Override
public void onCompleted() {
System.out.println("completed");
}
@Override
public void onError(Throwable e) {
error.set(e);
System.out.println("error");
e.printStackTrace();
}
@Override
public void onNext(String v) {
int num = Integer.parseInt(v);
System.out.println(num);
// doSomething(num);
count.incrementAndGet();
}
});
assertEquals(2, count.get());
assertNotNull(error.get());
if (!(error.get() instanceof NumberFormatException)) {
fail("It should be a NumberFormatException");
}
} |
Unit test added in #353 |
Unit test for ReactiveX#217
Unit test for ReactiveX#217
…tiveX#217) * Feature ReactiveX#215 ignore and record exceptions * Feature ReactiveX#215 ignore and record exceptions * 215 Cleanup and changed test * 215 removed super
The
take
operator from pull request #212 and merged in #215 does not handleObserver.onNext
throwing exceptions.This unit test reveals it:
It silently fails with a count of 2 and never prints an exception or throws anything.
The text was updated successfully, but these errors were encountered: