最后，如果一个嵌套的task取消或者发生错误呢？我们设置主task状态，再也不会调用迭代器。可能是在一个using块，或带有finally的try块的内部，并且有一些清理要做。我们应当遵守过程在中断的时候使它结束，而不要等垃圾收集器去做这些。我们怎么做到呢？当然通过一个后续部分！
为了解决这些问题，我们从ToTask()中移走MoveNext()调用，取而代之一个对ToTaskDoOneStep()的初始化的同步调用。然后我们将在一个提防增加合适的异常处理。
最终版本
这里是ToTask<T>()的最终实现. 它用一个TaskCompletionSource返回主task，永远不会引起线程等待，如果有的话还会涉及SynchronizationContext，由迭代器处理异常，直接传播嵌套task的结束（而不是AggregateException）,合适的时候向主task返回一个值，当期望一个结果而SLAM迭代器没有以正确的genericTask<T>类型结束时，用一个友好的异常报错。
public static Task<TResult> ToTask<TResult>(this IEnumerable<Task> tasks) { var taskScheduler = SynchronizationContext.Current == null ? TaskScheduler.Default : TaskScheduler.FromCurrentSynchronizationContext(); var taskEnumerator = tasks.GetEnumerator(); var completionSource = new TaskCompletionSource<TResult>(); // Clean up the enumerator when the task completes. completionSource.Task.ContinueWith(t => taskEnumerator.Dispose(), taskScheduler); ToTaskDoOneStep(taskEnumerator, taskScheduler, completionSource, null); return completionSource.Task; } private static void ToTaskDoOneStep<TResult>( IEnumerator<Task> taskEnumerator, TaskScheduler taskScheduler, TaskCompletionSource<TResult> completionSource, Task completedTask) { // Check status of previous nested task (if any), and stop if Canceled or Faulted. TaskStatus status; if (completedTask == null) { // This is the first task from the iterator; skip status check. } else if ((status = completedTask.Status) == TaskStatus.Canceled) { completionSource.SetCanceled(); return; } else if (status == TaskStatus.Faulted) { completionSource.SetException(completedTask.Exception); return; } // Find the next Task in the iterator; handle cancellation and other exceptions. Boolean haveMore; try { haveMore = taskEnumerator.MoveNext(); } catch (OperationCanceledException cancExc) { completionSource.SetCanceled(); return; } catch (Exception exc) { completionSource.SetException(exc); return; } if (!haveMore) { // No more tasks; set the result (if any) from the last completed task (if any). // We know it's not Canceled or Faulted because we checked at the start of this method. if (typeof(TResult) == typeof(VoidResult)) { // No result completionSource.SetResult(default(TResult)); } else if (!(completedTask is Task<TResult>)) { // Wrong result completionSource.SetException(new InvalidOperationException( "Asynchronous iterator " + taskEnumerator + " requires a final result task of type " + typeof(Task<TResult>).FullName + (completedTask == null ? ", but none was provided." : "; the actual task type was " + completedTask.GetType().FullName))); } else { completionSource.SetResult(((Task<TResult>) completedTask).Result); } } else { // When the nested task completes, continue by performing this function again. taskEnumerator.Current.ContinueWith( nextTask => ToTaskDoOneStep(taskEnumerator, taskScheduler, completionSource, nextTask), taskScheduler); } }
瞧! 现在你会在Visual Studio 2010中用没有async和await的 C#4 (或 VB10)写SLAMs(看起来同步的方法,但异步执行)。
有趣的地方
直到最后那个版本，我一直在给ToTask()传递一个CancellationTokenUp，并且将它传播进后续部分的ToTaskDoOneStep()。（这与本文毫不相关，所以我去掉了它们。你可以在样例代码中看注释掉的痕迹。）这有两个原因。第一，处理OperationCanceledException时，我会检查它的CancellationToken以确认它与这个操作是匹配的。如果不是，它将用一个错误来代替取消动作。虽然技术上没错，但不幸的是取消令牌可能会混淆，在其传递给ToTask()调用和后续部分之间的无关信息使它不值得。（如果你们这些 Task专家能给我一个注释里的可确认发生的好的用例，我会重新考虑）
第二个原因是我会检查令牌是否取消，在每次MoveNext()调用迭代器之前,立即取消主task时，和退出进程的时候。这使你可以不经过迭代器检查令牌，具有取消的行为。我不认为这是要做的正确事情（因为对一个异步进程在yield return处取消是不合适的）——更可能是它完全在迭代器进程控制之下——但我想试试。它无法工作。我发现在某些情形，task会取消而却后续部分不会触发。请看样例代码；我靠继续执行来恢复按钮可用，但它没有发生因此按钮在进程结束之后仍不可用。我在样例代码中留下了注释掉的取消检测；你可以将取消令牌的方法参数放回去并测试它。（如果你们Task专家能解释为什么会是这种情形，我将很感激！）
您可能感兴趣的文章: