How to throw an exception from within an Observer

[Dorvaryn]

Hi,

I am trying to make the app fail fast when something is going wrong from the Observer.
I was surprised to see that the Exception was swallowed by RxJava.

Here is a sample I tried :

 Observable.error(new Exception()).subscribe(new Observer<Object>() {
                    @Override
                    public void onCompleted() {

                    }

                    @Override
                    public void onError(Throwable e) {
                        throw new IllegalStateException("This should crash the app");
                    }

                    @Override
                    public void onNext(Object o) {

                    }
                });

Do I need do do anything specific to fail from within an Observer ?

[zsxwing]

According to Rx contract, onError will be called only once. So you need to handle the exception in onError by yourself.

[Dorvaryn]

I understand that onError is called only once, I'm not trying to forward the exception to something else. What I want to do is be able to throw a RuntimeException to make the app terminate.

[zsxwing]

RxJava will catch Exception and most Error. You can not propagate Exception out of RxJava. I'm curious why you have such requirement.

[Dorvaryn]

I get why catching all errors from within the flow of RxJava (ie observables, functions etc..) to keep the monadic properties but once you reach the Observer the flow is consumed and this the point in the app where you can act on the events. The idea here is to fail fast in order to identify easily developer errors during the development phase. I was under the assumption after reading this closed issue #650 that RxJava should not be swallowing exceptions from within an Observer.

[zsxwing]

#650 is out of date. The Observer is not only used by users, but also by RxJava. Observer is also used to build operators. In my opinion, Observable is often asynchronous. It means Observer often runs in other thread instead of the main thread. Even if RxJava throws the RuntimeException, it only crash the thread. That's still hard to debug. I suppose that forcing users to handle the exception is a better idea.

[Dorvaryn]

I didn't realise that some operator might be using Observers internally, makes more sense now.
I am handling the exceptions properly, I just wanted to figure out a way to make unexpected failures resulting from developer errors to be easier to spot. I suppose I'll rely on visual indication and Logs for now.

[benjchristensen]

This is an odd use case ... and it skips over the Exceptions.throwIfFatal() line in subscribe and swallows the error: https://github.com/Netflix/RxJava/blob/master/rxjava-core/src/main/java/rx/Observable.java#L7094

Not ideal at all.

I think we may need to make SafeSubscriber use an Exception other than RuntimeException that is considered "fatal" so we don't end up in loops where observer.onError throws and then subscribe tries to re-send it right back to observer.onError again only to get ignored by SafeSubscriber that allows only a single terminal state.

See here for the RuntimeException that should get thrown all the way up: https://github.com/Netflix/RxJava/blob/master/rxjava-core/src/main/java/rx/observers/SafeSubscriber.java#L171

[mttkay]

Sorry for reviving an old discussion.

We also run into the same issue, and the change that went in does not really help us. Rx contract or not, I think I agree with @Dorvaryn that certain errors should simply terminate the app, since they can signal developer error rather than anticipated runtime errors.

A good example are precondition checks and assertions. Guava for instance throws IllegalArgumentException when a precondition failed. This will throw during an onNext call. Why would I want to handle this within the Rx call chain? As a developer I violated a method contract and should be informed immediately--by seeing the app crash. The same goes for null pointers.

The way this is dealt with right now:

• a static Exceptions.throwIfFatal method which cannot be overridden, and which does not account for above mentioned cases
• a plugin system for errors, but which is safe guarded against from re-throwing errors, so this is not an option either

While I do see your points, I think there is definitely a case to be made for failing early, outside the Rx contract (since you want to terminate the app, why would breaking the Rx contract matter anyway?) It would go a long way to make Rx based apps easier to debug, since more often than not, errors you expect to fail the app simply disappear in the safe guards applied by SafeSubscriber.

[mttkay]

Actually, a much simpler way to solve this would be to change throwIfFatal to always rethrow Errors, and not just the 4 specific ones it checks for? That way we could wrap e.g. argument checks in AssertionError and have it terminate early.

Was there any particular reason why only 4 kinds of errors are rethrown from throwIfFatal? There's other kinds of errors like NoClassDefFoundError that should probably be considered fatal as well. I always assumed anything derived from Error is considered fatal anyway.

[benjchristensen]

Generally errors should be emitted to onError otherwise systems can end up hanging and/or leak resources because they never receive a terminal event (onComplete/onError) and therefore never releases user requests, unsubscribed for cleanup, etc. Only fatal errors are thrown, and the OnErrorNotImplementedException after the terminal event ensures everything receives an unsubscribe.

Ben Christensen
310.782.5511 @benjchristensen

On Jun 24, 2014, at 2:00 PM, Matthias Käppler notifications@github.com wrote:

Actually, a much simpler way to solve this would be to change throwIfFatal to always rethrow Errors, and not just the 4 specific ones it checks for? That way we could wrap exceptions in AssertionError and have it terminate early.

Was there any particular reason why only 4 kinds of errors are rethrown from throwIfFatal? There's other kinds of errors like NoClassDefFoundError that should probably be considered fatal as well. I always assumed anything derived from Error is considered fatal anyway.

—
Reply to this email directly or view it on GitHub.

[mttkay]

Sure, but why is something like NoClassDefFound not considered fatal? According to Java's Error doc, all subclasses are considered fatal.