Fix that exceptions will be swallowed by schedulers (#6954) #6955
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fix that RxJava will miss exceptions in Future thrown by tasks executed by
executors
Signed-off-by: jiaoxiaodong [email protected]
In general, exceptions should never be swallowed and should be handled somewhere, eg., catch clause or uncaught exception handlers of threads.
As to RxJava, exceptions are expected to be handled at:
and not to be magically swallowed somewhere.
This is true in most situations, but is broken when schedulers are involved. That is, the following tests will fail:
(Test 1) Exceptions from observables are swallowed:
(Test 2) Exceptions from observers are swallowed:
Sometimes these broken cases matter in certain situation or on certain platform, eg.,
The cause is clear. Internal to Scheduler implementation, RxJava only uses Future of a task submitted to Executor as a cancel-handle and never check exceptions inside the Future while any exception thrown by the submitted task will go into the Future.
But the fix is not as easy, there is no chance to check the Future for exception since RxJava pushes task result instead of pulls it.
Pulling results is the design intent of Future. When we won't, I think we should customize the FutureTask which runs the task in Executor and provides the Future function to give us a chance to handle the result(including the exception).
Actually, JDK has given us all we need to do this via ThreadPoolExecutor#newTaskFor, ScheduledThreadPoolExecutor#decorateTask, RunnableFuture, RunnableScheduledFuture, etc. And Android did something similar in its AsyncTask implementation.
I'll propose a PR that: