dotnet/Documentation/compatibility/change-in-behavior-for-task...

42 lines
1.8 KiB
Markdown

## Change in behavior for Task.WaitAll methods with time-out arguments
### Scope
Minor
### Version Introduced
4.5
### Source Analyzer Status
Available
### Change Description
Task.WaitAll behavior was made more consistent in .NET 4.5.
In the .NET Framework 4, these methods behaved inconsistently. When the time-out
expired, if one or more tasks were completed or canceled before the method call,
the method threw an <xref:System.AggregateException?displayProperty=name>
exception. When the time-out expired, if no tasks were completed or canceled
before the method call, but one or more tasks entered these states after the
method call, the method returned false.<br/><br/>In the .NET Framework 4.5,
these method overloads now return false if any tasks are still running when the
time-out interval expired, and they throw an
<xref:System.AggregateException?displayProperty=name> exception only if an input
task was cancelled (regardless of whether it was before or after the method
call) and no other tasks are still running.
- [ ] Quirked
- [ ] Build-time break
### Recommended Action
If an <xref:System.AggregateException?displayProperty=name> was being caught as a means of detecting a task that was cancelled prior to the WaitAll call being invoked, that code should instead do the same detection via the IsCanceled property (for example: .Any(t =&gt; t.IsCanceled)) since .NET 4.6 will only throw in that case if all awaited tasks are completed prior to the timeout.
### Affected APIs
* `M:System.Threading.Tasks.Task.WaitAll(System.Threading.Tasks.Task[],System.Int32)`
* `M:System.Threading.Tasks.Task.WaitAll(System.Threading.Tasks.Task[],System.Int32,System.Threading.CancellationToken)`
* `M:System.Threading.Tasks.Task.WaitAll(System.Threading.Tasks.Task[],System.TimeSpan)`
### Category
Core
<!-- breaking change id: 26 -->