Stacktraces and subscribeOn/observeOn
See original GitHub issueRxJava in not nice when it comes to stacktraces.
The worst thing is observeOn
that schedules execution on different threads. Every time we use observeOn
we get our stacktrace from the process root, all the call history gets erased.
The idea is to make schedulers save the caller’s stack, wrap action calls and attach the stacktrace to each exception that has been thrown by scheduled actions.
Pros: traceable exceptions Cons: Performance cost Leaks because of recursion
I think that we can have Schedulers.io(boolean trace)
alternative that will save the stacktrace, so we could call it Schedules.io(DEBUG)
to turn stacktracing off on production for performance critical parts.
How do you guys find this idea?
Issue Analytics
- State:
- Created 8 years ago
- Reactions:3
- Comments:46 (12 by maintainers)
Top Results From Across the Web
Understanding RxJava subscribeOn and observeOn
One of the biggest strengths of RxJava is its ability to easily schedule work and process results on various threads.
Read more >RxJava: observeOn, subscribeOn, and doFinally, switching ...
I am running into an issue where my observable is subscribed on an IO thread and observed on the android main (UI) thread...
Read more >Towards fixing RxJava stacktrace - Medium
Unreadable RxJava error stacktrace is a known problem. ... There is also case when RxJava swallows error (e.g. subscribeOn with any Rx scheduler)...
Read more >The `Single` Issue with RxLifecycle - Thrive Mobile
A simple search revealed the answer. We were using RxLifecycle without understanding how it terminates subscriptions. We thought it was ...
Read more >ReactiveX/RxJava - Gitter
@httpdispatch I did try with both observeOn() and subscribeOn() same result ... The stacktrace indicates it fails to emit in a BehaviorProcessor.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Since this is the top Google result for
rxjava observeon stack trace
, I’d like to point everybody (and myself next time I search for this) to the excellent Traceur library which solved this issue for me. It’s a library for RxJava2 which replicates RxJava1’sRxJavaHooks.enableAssemblyTracking()
.Here is the solution I came up with.
Just add
.lift(traceOnError())
to a chain to get localized stacktraces.P.S. It will not help with the case of the bloking operator error because the exception happens after
.lift(traceOnError())
.