TaskObservationOptions class¶

Summary¶

Controls how completion or failure is handled when a Task or Task is wrapped as an IObservable and observed by an IObserver.

Remarks¶

This type can be passed to overloads of the various method that adapt a TPL task as an IObservable. It deals with two concerns that arise whenever this is done: the scheduler through which notifications are delivered, and the handling of exceptions that occur after all observers have unsubscribed.

If the Scheduler property is non-null, it will be used to deliver all notifications to observers, whether those notifications occur immediately (because the task had already finished by the time it was observed) or they happen later.

The IgnoreExceptionsAfterUnsubscribe property determines how to deal with tasks that fail after unsubscription (i.e., if an application calls Subscribe on an observable wrapping, then calls Dispose on the result before that task completes, and the task subsequently enters a faulted state). Overloads that don't take a TaskObservationOptions argument do not observe the Exception in this case, with the result that the exception will then emerge from UnobservedTaskException (which could terminate the process, depending on how the .NET application has been configured). This is consistent with how unobserved Task failures are normally handled, but it is not consistent with how Rx handles post-unsubcription failures in general. For example, if the projection callback for Select is in progress at the moment an observer unsubscribes, and that callback then goes on to throw an exception, that exception is simply swallowed. (One could argue that it should instead be sent to some application-level unhandled exception handler, but the current behaviour has been in place for well over a decade, so it's not something we can change.) So there is an argument that post-unsubscribe failures in IObservable-wrapped tasks should be ignored in exactly the same way: the default behaviour for post-unsubscribe failures in tasks is inconsistent with the handling of all other post-unsubscribe failures. This has also been the case for over a decade, so that inconsistency of defaults cannot be changed, but the IgnoreExceptionsAfterUnsubscribe property enables applications to ask for task-originated post-unsubscribe exceptions to be ignored in the same way as non-task-originated post-unsubscribe exceptions are. (Where possible, applications should avoid getting into situations where they throw exceptions in scenarios where nothing is able to observe them is. This setting is a last resort for situations in which this is truly unavoidable.)

Constructors¶

Properties¶