1

IObservable<T>.Subscribe 的重载之一是

public static IDisposable Subscribe<T>(this IObservable<T> source, Action<T> onNext)

在内部，这会AnoymousObserver<T>在 IObservable 上创建并注册一个。未指定的onError参数设置为Stubs.Throwwhich 是一个简单的 lambda，它重新抛出传入的异常。

在内部，IObservable 的观察者都包含在 Observer 类型的单个实例中。这是中的代码Observer<T>.OnError

public void OnError(Exception error)
{
    foreach (var observer in _observers.Data)
        observer.OnError(error);
}

由于 Stubs.Throw 抛出异常，来自该观察者的 OnError 的异常通过 foreach 循环传递，并且 _observers.Data 中的其他观察者永远不会调用其 OnError。异常本身在 Rx 内部的某个地方被吞没了。

在我看来，要么 Observer<T>.OnError 应该将 observer.OnError 包装在 try-catch 中，要么 Stubs.Throw 应该吞下异常而不是抛出它。通过不传递 onError 参数，IObservable.Subscribe 的用户希望仅对该订阅忽略错误。使用自己的 onError 回调注册的其他订阅者应该不受影响。

（我已经在 Codeplex 上提交了一个错误，但跟踪器看起来很冷清，所以我想我也会问一下 SO，看看我是否理解正确。）

更新：阿斯蒂的回答是正确的。在关于链接的错误报告的讨论中，davedev 与 IEnumerable 进行了类比，并且默认抛出未处理的异常如何等同于在没有 catch 块的情况下迭代 IEnumerable 的默认值。

如果 observable 确定不应将特定异常视为致命异常，则不应使用 OnError 进行通信。OnError 不能保证被执行，因为调用它意味着 observable 一开始就出现了严重错误。相反，observable 可以定义为 IObservable< Either <T, Exception>> （Observable2.Retry中的示例用法）。

4

1 回答 1

1

这实际上是预期的行为。

OnError不是一个方法被调用来指示异常被抛出到观察者的OnNext- 它是表示异常终止可观察序列。默认OnError实现将在通知转换出 Observable monad 时抛出异常。

如果您阅读Rx 设计指南，您将对 Rx 合同和异常处理有更清楚的了解。至于管道中的错误处理，以及更多类似IEnumerable/IQueryable的行为，请查看SubscribeSafe.

于 2013-01-21T12:10:47.703 回答