CompositeException fix for Android

[tomrozb]

Fixes #1405

• revert changes from f4ae92a
• remove duplicated causes in stack trace chain

[cloudbees-pull-request-builder]

RxJava-pull-requests #1385 FAILURE
Looks like there's a problem with this pull request

[benjchristensen]

This will take a while to review as those changes were done for good reason.

[tomrozb]

Maybe I should provide some explanation about what was wrong with the previous implementation.

Here's how most of Java programmers will rethrow an exception if not handled:

        Observable.create((Subscriber<? super Object> subscriber) ->
                subscriber.onError(new RuntimeException("ex1")))
                .observeOn(AndroidSchedulers.mainThread())
                .subscribeOn(Schedulers.io()).subscribe(
                object -> {
                    // ...
                }, error -> {
                    // handle some exceptions
                    ...
                    // rethrow unhandled
                    throw new RuntimeException("ex2", error);
                }
        );

Now we have CompositeException with two nested exceptions:

• ex1
• ex2 which cause is ex1

The previous implementation will create a loop in this situation:

OnErrorFailedException
   CompositeException
      ex1
         ex2
             ex1
                 ex2
                     ...

I've provided test for this scenario and additional method to remove throwables which are causes of another throwable. It means ex1 will not be attached as a cause of the CompositeException because it is a cause of ex2 so it will be automatically attached with ex2 and printed in the stack trace output.

OnErrorFailedException
   CompositeException
         ex2
             ex1

[benjchristensen]

/cc @mattrjacobs Matt, can you get involved here (now that you're back) since you have the most recent history and context in this code. Discussion at #1405

[mattrjacobs]

Given the new constraint that Android does something unexpected (to me anyway) with the set of printStackTrace methods, it's probably preferable to modify the structure of CompositeException, so that any arbitrary output of a CompositeException is correct. Relying on the implementation details of precisely how Android does the printStackTrace doesn't protect us from any other edge cases.

So I generally think the sort of change proposed by @tomrozb is good - I'm validating what the output looks like in our prod env now. Thanks @tomrozb for the PR.

[mattrjacobs]

I'm merging this now, thanks for the clear explanation, and fix with a test, @tomrozb.

[benjchristensen]

Thanks @mattrjacobs and @tomrozb