You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since RxJava modifies exceptions during call of getCause method of CompositeException instance and connect these exceptions in chains we have finally millions of exceptions and quickly getting out of memory.
The getCause looks needlessly convoluted. I presume it was implemented that way that IDEs show some usable stacktraces of the individual inner exceptions. Java 7's addSuppressed is better in this regard but we can't use it just yet.
I can probably have such duplicate indicator show up at most once.
I see. To resolve it, we'd have to remove the custom getCause implementation otherwise it will keep touching all sorts of inner exceptions. We could also probably fake a StackTraceElement array containing all inner exceptions too.
Thanks for reporting. This is a shortcoming of the 1.x and 2.x composite design and I'm afraid we can only resolve this for 3.x because it is a breaking change in the structure of the composite verified by unit tests.
Since RxJava modifies exceptions during call of
getCause
method ofCompositeException
instance and connect these exceptions in chains we have finally millions of exceptions and quickly getting out of memory.This simple test demonstrates that cause of
rootError
throwable is changed.The text was updated successfully, but these errors were encountered: