我使用简单的Subject<object>
在Web应用程序中实现Event Aggregator模式,如下所示:
public class EventAggregator
{
private readonly ISubject<object, object> _subject = Subject.Synchronize(new Subject<object>());
public IObservable<T> GetEvent<T>()
{
return _subject.AsObservable().OfType<T>();
}
public void Publish<TEvent>(TEvent sampleEvent)
{
_subject.OnNext(sampleEvent);
}
}
当运营商或订户抛出异常时,我想记录它然后忽略它并继续发布事件 - 本质上我希望流在某些意外行为的情况下“继续”,因为Event Aggregator有一个单例在应用程序的上下文中的生命周期。
在this question中,给出的答案是创建一个延迟的observable并使用Retry()
,但我不想在这里看到冷的可观察性。
我提出的解决方案是在订阅者方法中使用Catch
和try-catch,我将其包含在扩展中:
public static IDisposable SubscribeSwallowExceptions<T>(this IObservable<T> source, Action<T> subscription, Action<Exception> log)
{
source = source.Catch((Exception e) => { log(e); return source; });
return source.Subscribe(x =>
{
try { subscription(x); }
catch (Exception e) { log(e); }
});
}
我知道“catch-all”异常处理通常是不受欢迎的,但在这种情况下,我不确定我有什么其他选项,因为我希望订阅保留,即使抛出异常。我不知道可能会发生什么类型的异常,因为我还不知道在处理流时会做什么工作。
这是否是处理潜在异常的可接受方式,您能否预见到任何可能使我采用这种方法的问题?
答案 0 :(得分:1)
这是一个有问题的解决方案。一旦订阅者抛出异常,你必须真正假设他们已经死在水中(你 通过您的方法,“糟糕”的订阅者将继续发送事件,并可能无限期地抛出异常。
此外,您无法真正依赖使用您的扩展方法的订阅者。我会按如下方式重写您的GetEvent<T>
方法(显然用一些日志记录替换我的Console.WriteLine
)。这种方法将仅针对不良订户处理订阅,并让其他所有人都在运行。
public IObservable<T> GetEvent<T>()
{
return Observable.Create<T>(o =>
{
var source = _subject.OfType<T>();
var m = new SingleAssignmentDisposable();
m.Disposable = source.Subscribe(
x => {
try {
o.OnNext(x);
}
catch(Exception e) {
Console.WriteLine(e);
m.Dispose();
}
},
e => {
try {
o.OnError(e);
}
catch(Exception ex) {
Console.WriteLine(ex);
}
finally {
m.Dispose();
}
},
() => {
try {
o.OnCompleted();
}
catch(Exception e) {
Console.WriteLine(e);
}
finally {
m.Dispose();
}
}
);
return m;
});
}