TimeLimits

Trait that provides failAfter and cancelAfter methods, which allow you to specify a time limit for an operation passed as a by-name parameter, as well as a way to signal it if the operation exceeds its time limit.

The time limit is passed as the first parameter, as a Span. The operation is passed as the second parameter. A Signaler, a strategy for interrupting the operation, is passed as an implicit third parameter. Here's a simple example of its use:

failAfter(Span(100, Millis)) {
 Thread.sleep(200)
}

The above code will eventually produce a TestFailedDueToTimeoutException with a message that indicates a time limit has been exceeded:

The code passed to failAfter did not complete within 100 milliseconds.

If you use cancelAfter in place of failAfter, a TestCanceledException will be thrown instead, also with a message that indicates a time limit has been exceeded:

The code passed to cancelAfter did not complete within 100 milliseconds.

If you prefer you can mix in or import the members of SpanSugar and place a units value after the integer timeout. Here are some examples:

import org.scalatest.time.SpanSugar._

failAfter(100 millis) {
 Thread.sleep(200)
}

failAfter(1 second) {
 Thread.sleep(2000)
}

The code passed via the by-name parameter to failAfter or cancelAfter will be executed by the thread that invoked failAfter or cancelAfter, so that no synchronization is necessary to access variables declared outside the by-name.

var result = -1 // No need to make this volatile
failAfter(100 millis) {
 result = accessNetService()
}
result should be (99)

The failAfter or cancelAfter method will create a timer that runs on a different thread than the thread that invoked failAfter or cancelAfter, so that it can detect when the time limit has been exceeded and attempt to signal the main thread. Because different operations can require different signaling strategies, the failAfter and cancelAfter methods accept an implicit third parameter of type Signaler that is responsible for signaling the main thread.

== Configuring failAfter or cancelAfter with a Signaler ==

The Signaler companion object declares an implicit val of type Signaler that returns a DoNotSignal. This serves as the default signaling strategy. If you wish to use a different strategy, you can declare an implicit val that establishes a different Signaler as the policy. Here's an example in which the default signaling strategy is changed to ThreadSignaler, which does not attempt to interrupt the main thread in any way:

override val signaler: Signaler = ThreadSignaler
failAfter(100 millis) {
 Thread.sleep(500)
}

As with the default Signaler, the above code will eventually produce a TestFailedDueToTimeoutException with a message that indicates a timeout expired. However, instead of throwing the exception after approximately 500 milliseconds, it will throw it after approximately 100 milliseconds.

This illustrates an important feature of failAfter and cancelAfter: it will throw a TestFailedDueToTimeoutException (or TestCanceledException in case of cancelAfter) if the code passed as the by-name parameter takes longer than the specified timeout to execute, even if it is allowed to run to completion beyond the specified timeout and returns normally.

ScalaTest provides the following Signaler implementations:

You may wish to create your own Signaler in some situations. For example, if your operation is performing a loop and can check a volatile flag each pass through the loop, you could write a Signaler that sets that flag so that the next time around, the loop would exit.