Guard clauses for TimeoutPolicy now allow Timout.InfiniteTimeSpan (Issue #419)

[urig]

A TimeSpan value of Timeout.InfiniteTimeSpan indicates, well, an infinite timeout for the policy.

Please note this PR only addresses the sync version of the Policy. Async version to be address immediately following.

[dnfclas]

All CLA requirements met.

[reisenberger]

Thank you @urig , this is looking great!

Hmm. From the build error, it looks like .NET4.0 does not publicly expose the constant System.Threading.Timeout.InfiniteTimeSpan (altho my understanding is it behaves the same). So we may need to define our own constant:

internal static readonly TimeSpan InfiniteTimeSpan = System.Threading.Timeout.InfiniteTimeSpan;

and then use #if directive forking to just define it manually for .NET4.0. Probably pull that into a TimeoutSyntaxBase base class (thoughts?) along with the ValidateTimeoutIsInRange(...) method, as they'll be used across several syntax classes? (see below).

Let's also catch the:

/// <exception cref="System.ArgumentOutOfRangeException">

intellisense for the methods you're updating, update them to the nice new message from ValidateTimeoutIsInRange(...)!

I reckon that would be good to go then across the other syntax classes. There's a very similar TimeoutTResultSyntax.cs class for the generic (Policy<TResult>), synchronous versions of TimeoutPolicy. And then a similar pair (TimeoutSyntaxAsync.cs, TimeoutTResultSyntaxAsync.cs) for the async variants.

Thank you again for your contribution!

[urig]

I have some questions about this. Will try to catch you on Slack!

[reisenberger]

Thanks @urig . Merging! Will add credit and v5.9.0 doco for this later.