Difference in behaviour for onError between 1.x AsyncEmitter and Observable.create() 2.x

[hvisser]

RxJava version 2.0.4

While migrating to RxJava 2, I ran into some behavioural differences between 1.x fromAsync() and Observable.create(). In particular, the emitter passed into fromAsync handles onError() emissions after unsubscription differently from the 2.x one.

In 2.x, if onError() is invoked after the observable is disposed (e.g. emitter.isDisposed() returns true), the error is routed to the default onError() handler, resulting in an unhandled exception. This means that when emitting an error event, this should be guarded with a check to emitter.isDisposed(). onNext() and onCompleted events after disposal are discarded like before in 1.x

In 1.x this is not the case, and the emitter will just ignore the error emission if the observable has been unsubscribed.

2.x: https://github.com/ReactiveX/RxJava/blob/2.x/src/main/java/io/reactivex/internal/operators/observable/ObservableCreate.java#L72

1.x https://github.com/ReactiveX/RxJava/blob/1.x/src/main/java/rx/internal/operators/OnSubscribeFromEmitter.java#L105

Personally I prefer the 1.x behaviour because it's less error prone and doesn't require a guard using isDisposed(). Also because of this, migrating existing 1.x code to 2.x can be problematic. It took me a while to figure out why an error was thrown even though all of my subscriptions have explicit error handling.

[akarnokd]

One of the 2.x design principles was that no errors should get lost. These are errors that can't be emitted because the consumer lifecycle doesn't allow it. In 1.x, it probably fell to the floor but 2.x by default calls Thread.getUncaughtExceptionHandler().uncaughtException() which crashes the app on Android and has no effect on desktop. We tried to come up with a less drastic approach but currently there is no way to distinguish between truly fatal errors and errors that can't be delivered due to cancellation/lifecycle restrictions. What's left is to define your own global error handler which can just ignore all errors.

[hvisser]

OK, I get that, but would truly fatal errors be error that are uncaught, and not going through onError?

…

On Thu, Jan 19, 2017, 21:23 David Karnok ***@***.***> wrote: One of the 2.x design principles was that no errors should get lost. These are errors that can't be emitted because the consumer lifecycle doesn't allow it. In 1.x, it probably fell to the floor but 2.x by default calls Thread.getUncaughtExceptionHandler().uncaughtException() which crashes the app on Android and has no effect on desktop. We tried to come up with a less drastic approach but currently there is no way to distinguish between truly fatal errors and errors that can't be delivered due to cancellation/lifecycle restrictions. What's left is to define your own global error handler which can just ignore all errors. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#5009 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA06EtjVmhe6xKeV0IaqdoVfTYazb9Rtks5rT8YzgaJpZM4Loic4> .

[akarnokd]

That's another category.

[hvisser]

OK can I at least request to wrap that error path in some kind of extra exception, like IllegalStateException? It literally took me several hours to pinpoint where that error was coming from. I'd like to save that hours for others ;) It looks like a "normal" unhandled exception, while in fact it's not really.

[akarnokd]

The current workaround is to overrider the global error handler or with a consumer of your chosing where you can add your exception wrapper as you see fit.

[hvisser]

Overriding the global error handler is not something that I want; I still want to crash on unexpected errors that occur when I use the subscribe() overload without an error handler. I'm not sure what you mean with "a consumer of your choosing"? Can you give an example?

The issue here is that even if I'd use a consumer that handles the error (which I am), that error would never end up there because the consumer has unsubscribed / disposed by then. (Sorry if I mix up v1 with v2 lingo here)

[akarnokd]

You see the problem now; on the RxJava level we can't distinguish between wanted and unwanted errors that are raised beyond the lifecycle (or cancellation).

I'm not sure what you mean with "a consumer of your choosing"? Can you give an example?

See the wiki link I posted.

[hvisser]

OK, got it, thanks for the help.

[hvisser]

Turns out that my the situation was a bit more complex:

• The Cancellable set on the emitter could cause an exception being thrown (a blocking wait), which would be passed on to onError()
• unsubscribeOn() was applied, so cancellation would happen in a different thread
• It looks like emitter.isDisposed() would not always be true at the point in time the exception was being thrown (but I'm not 100% sure)

I fixed this now by having a flag set once the Cancellable is invoked, checking that before emitting onError().

I'll try to produce a test case and file a new issue if anything comes out of that.