2.x Emitting an error to terminated `Subject` could have an explanation [Proposal]

[neworld]

I eitting an error to terminated subject. Example code:

val subject = BehavioralSubject.create<Unit>()
subject.onError(RuntimeException(""))
subject.onError(RuntimeException("")) //this error goes to Rx error handler.

That error is handled here:

RxJava/src/main/java/io/reactivex/subjects/BehaviorSubject.java

Line 194 in d3455d0

RxJavaPlugins.onError(t);

Maybe, would be nice, if that error will be wrapped into another exception, which explains, why this error goes to Rx error handler. Example:

RxJavaPlugins.onError(RuntimeException("Can't emit the error in terminated subject", t)

[akarnokd]

Why do you have two onError calls?

[neworld]

In my case, I am upgrading to 2.x, and I got failing a test in spaghetti code (250 lines, subject is processed everywhere). 1.x code was green but 2.x red. I had read Rx implementation details to realize, that second error goes straight to an error handler. This little explanation would be saved some time.

[akarnokd]

RxJava 2 no longer swallows such excess errors but routes them to the current thread's uncaught exception handler, which happens to crash the app on Android. There are cases which should legitimately crash your app, as @JakeWharton expressed, but RxJava can't differentiate among them. We recently reintroduced OnErrorNotImplementedException as the means to distinguish bad usages of subscribe, but likely every other RxJavaPlugins.onError invocation is due to end-of-lifecycle (like your second onError hitting an already terminated Subject`).

This little explanation would be saved some time

Let me see what it takes to add a wrapper exception around all other RxJavaPlugins.onError invocation.

[neworld]

That OnErrorNotImplementedException confuses me. I understood what you mean. Thanks for the explanation. Let's close this.

[akarnokd]

See #5080.

[neworld]

That is exactly what I mean. Thanks.