Bug in Rx? Inconsistent exception handling on TaskPoolScheduler

[mattpodwysocki]

Bug in Rx? Inconsistent exception handling on TaskPoolScheduler

[mattpodwysocki]

whirly wrote Nov 28, 2013 at 3:20 PM

Just see the source code comments:

            //
            // BREAKING CHANGE v2.0 > v1.x - No longer escalating exceptions using a throwing
            //                               helper thread.
            //
            // Our manual escalation based on the creation of a throwing thread was merely to
            // expedite the process of throwing the exception that would otherwise occur on the
            // finalizer thread at a later point during the app's lifetime.
            //
            // However, it also prevented applications from observing the exception through
            // the TaskScheduler.UnobservedTaskException static event. Also, starting form .NET
            // 4.5, the default behavior of the task pool is not to take down the application
            // when an exception goes unobserved (done as part of the async/await work). It'd
            // be weird for Rx not to follow the platform defaults.
            //
            // General implementation guidelines for schedulers (in order of importance):
            //
            //    1. Always thunk through to the underlying infrastructure with a wrapper that's as tiny as possible.
            //    2. Global exception notification/handling mechanisms shouldn't be bypassed.
            //    3. Escalation behavior for exceptions is left to the underlying infrastructure.
            //
            // The Catch extension method for IScheduler (added earlier) allows to re-route
            // exceptions at stage 2. If the exception isn't handled at the Rx level, it
            // propagates by means of a rethrow, falling back to behavior in 3.
            //