What would be a real world usage or need of the Rx operator Never?

Question

Why would you ever subscribe to or even create an observable that never yields anything, not even an error, nor completion?

Answer 1

It is a fundamental "atom" in the composition of observable event streams and comes up in a variety of situations - but one of the most common uses for Observable.Never in practice is in writing tests. It easily enables robust checking of timeout logic, for example - and is often combined with the TestScheduler or other virtual time schedulers in test scenarios. If you examine the source code of Rx itself, you find it appears in many unit tests.

Answer 2

I've seen it used with Observable.Window and Observable.Buffer for the closing observable. This is a trivial example as the real code is too complex to post.

static IObservable<Unit> CloseWindow(int interval)
{
    if (interval <= 0)
    {
        return Observable.Never<Unit>();
    }

    return Observable.Interval(TimeSpan.FromSeconds(interval)).Select(_ => Unit.Default);
}

Use when grouping data for analyst and sometimes it requires all the data and sometimes not. Again trivial example

static IObservable<double> AverageOfWindow(IObservable<int> source, int interval)
{
    return source.Buffer(CloseWindow(interval)).Select(o => o.Average());
}

If using Empty it would never produce a result and by using Never it's basically by passing the Buffer and Window methods. Could write the observable to skip the Buffer when it's not needed but easier and less code to maintain if the CloseWindow has all the logic to determine when the close the buffer sequence. Again in this example it's trivial but in real code the logic to decide when the buffer closes is more complex.

Answer 3

I have considered this myself. The conclusion I came to is that frameworks that you take a dependency on would use this (or you would use this if you are creating a framework). I see it as the equivalent of an empty IEnumerable. Consider the case where you call a method that returns an IEnumerable. Perhaps the IEnumerable that is returned from the method depends on the parameters passed to the method; there may be no data to be returned in some cases. Some... people (I struggled with a few choice words here) might return null but a more enlightened developer would return an empty IEnumerable. I see an observable that never yields anything as being equivalent to an empty IEnumerable. Of course, you could make the argument that Observable.Empty (which returns an observable that completes immediately) is really the equivalent of an empty IEnumerable but I think it probably depends on the situation. Whoever is designing the framework would have to decide which is semantically correct, Observable.Empty or Observable.Never.

That's my two cents. Perhaps somebody will have a better reason.