如果我在Observable的Subscribe回调中引发异常，应该怎么办？

Question

I'm using the latest Reactive Extensions and have run into a design issue:

What should happen if I throw an exception from the delegate I pass into Subscribe?

Via source stepping, I have found:

• Subjects will ignore the exception.
• Operators derived from Producer (such as Where ) dispose the subscription as the exception passes through them.

So of course I've been finding that anywhere I pass an observable through a standard RX operator, any exception causes my events to stop right there due to the disposal. At least, unless I re-subscribe.

This is leading me to question my design. Is it a bad idea to throw exceptions from my delegates? Clearly the RX team thinks so. (Though I'd question whether silently disposing the "bad" subscription is the right way to go.)

Looking at my design, though, I don't see why it's a problem. I have some protected operations going on, I start firing some OnNext's to notify listeners (we have fully switched over from old skool .NET events to Observables), if anything goes wrong in there, it will throw up the stack until it hits a handler. In my case, the handler rolls back a transaction it's working on, which also notifies the listeners of the rollback. It's all exception-safe, works fine. At least, it works fine without the Dispose going on in the Where operator's Producer base.

Going a little further.. is it inconsistent that Subject and peers don't do this behavior? And for our own ISubjects and observable operators that we've written here, should we be doing this same dispose-on-exception behavior?

I'm looking forward to any insights!

Answer 1

Throw exceptions when there are problems. Catch them when you think you can deal with the problems they indicate. Language support for exception handling assumes you have a function call stack and so the exception just climbs the stack looking for a handler.

But remember when using Rx, the processing model has been turned sideways. You no longer have a deep function call stack with the source (calling code) at the top and the observer (called code) at the bottom. So you cannot rely on the language to do the right thing within your Rx stream.

If your callback throws an exception then Rx tends to capture that exception and pass it down through the OnError channel of the observable. If you do not supply an OnError handler when you subscribe, then Rx tends to raise the exception on a background thread, generating an unhandled exception in your application.

Rx does not notify the datasource that something downstream has had an exception. This is because the datasource is completely isolated from the data consumers. It might not be on the same process or even the same machine or written in the same language. That is why the Subject does not do anything. The Subject is acting as the data source in this case and doesn't really care about what observers do.

As you've noted, uncaught exceptions will cause Rx to unsubscribe your observer from the observable by default. This is the fail-fast philosophy and is the only safe assumption Rx can make. If your observer raised an exception then something must be wrong and we should not give it more data by default. Rx provides mechanisms that let you handle exceptions in ways that do not necessarily unsubscribe from the observable.

One way is to turn your exceptions into data:

// instead of:
source.Where(foo => predicateThatMightThrowException(foo)).Subscribe(foo => ..., error => ...)

// do:
source.Select(foo =>
{
    try { return new { foo: foo, filter: predicateThatMightThrowException(foo), error: (Exception)null }; }
    catch (Exception e) { return { foo: foo, filter: true, error: e } };
})
.Where(f => f.filter)
.Subscribe(f =>
{
    if (f.error != null) { handle error }
    else { handle f.foo }
});

Other ways involve using CatchException or Retry . The Rxx library has some paired observables with left/right channels and an Either type that you can use to stream your good data on the "left" and your errors on the "right".

Answer 2

Ok, I found my answer in the source. Will simply paste it here for posterity.

// Safeguarding of the pipeline against rogue observers is required for proper
// resource cleanup. Consider the following example:
//
//   var xs  = Observable.Interval(TimeSpan.FromSeconds(1));
//   var ys  = <some random sequence>;
//   var res = xs.CombineLatest(ys, (x, y) => x + y);
//
// The marble diagram of the query above looks as follows:
//
//   xs  -----0-----1-----2-----3-----4-----5-----6-----7-----8-----9---...
//                  |     |     |     |     |     |     |     |     |
//   ys  --------4--+--5--+-----+--2--+--1--+-----+-----+--0--+-----+---...
//               |  |  |  |     |  |  |  |  |     |     |  |  |     |
//               v  v  v  v     v  v  v  v  v     v     v  v  v     v
//   res --------4--5--6--7-----8--5--6--5--6-----7-----8--7--8-----9---...
//                                 |
//                                @#&
//
// Notice the free-threaded nature of Rx, where messages on the resulting sequence
// are produced by either of the two input sequences to CombineLatest.
//
// Now assume an exception happens in the OnNext callback for the observer of res,
// at the indicated point marked with @#& above. The callback runs in the context
// of ys, so the exception will take down the scheduler thread of ys. This by
// itself is a problem (that can be mitigated by a Catch operator on IScheduler),
// but notice how the timer that produces xs is kept alive.

So the answer is: yes, it's a bad idea to throw exceptions in OnNext. In general. In my specific case I know it's ok, so I am going to find another way.