Executes the passed function, enforcing the passed time limit by attempting to signal the operation if the
time limit is exceeded, and "canceling" if the time limit has been
exceeded after the function completes, where what it means to "cancel" is determined by the implicitly passed Timed[T]
instance.
Executes the passed function, enforcing the passed time limit by attempting to signal the operation if the
time limit is exceeded, and "canceling" if the time limit has been
exceeded after the function completes, where what it means to "cancel" is determined by the implicitly passed Timed[T]
instance.
The Timed
companion object offers three implicits, one for FutureOutcome
, one for Future[U]
and one for any other type. The implicit Timed[FutureOutcome]
defines cancelation as canceling the FutureOutcome
:
no exception will be thrown. The implicit Timed[Future[U]]
defines canceling as failing the Future[U]
with a TestCanceledException
:
no exception will be thrown. The implicit for any other type defines failure as throwing
TestCanceledException
. For the details, see the Scaladoc of the implicit Timed
providers
in the Timed
companion object.
the maximimum amount of time allowed for the passed operation
a strategy for signaling the passed operation
a Prettifier
for prettifying error messages
the Position
of the caller site
the Timed
type class that provides the behavior implementation of the timing restriction.
Executes the passed function, enforcing the passed time limit by attempting to signal the operation if the
time limit is exceeded, and "failing" if the time limit has been
exceeded after the function completes, where what it means to "fail" is determined by the implicitly passed Timed[T]
instance.
Executes the passed function, enforcing the passed time limit by attempting to signal the operation if the
time limit is exceeded, and "failing" if the time limit has been
exceeded after the function completes, where what it means to "fail" is determined by the implicitly passed Timed[T]
instance.
The Timed
companion object offers three implicits, one for FutureOutcome
, one for Future[U]
and one for any other type. The implicit Timed[FutureOutcome]
defines failure as failing the FutureOutcome
with a TestFailedDueToTimeoutException
:
no exception will be thrown. The implicit Timed[Future[U]]
defines failure as failing the Future[U]
with a TestFailedDueToTimeoutException
:
no exception will be thrown. The implicit for any other type defines failure as throwing
TestFailedDueToTimeoutException
. For the details, see the Scaladoc of the implicit Timed
providers
in the Timed
companion object.
the maximimum amount of time allowed for the passed operation
the operation on which to enforce the passed timeout
a strategy for signaling the passed operation
a Prettifier
for prettifying error messages
the Position
of the caller site
the Timed
type class that provides the behavior implementation of the timing restriction.
Trait that provides
failAfter
andcancelAfter
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. ASignaler
, a strategy for interrupting the operation, is passed as an implicit third parameter. Here's a simple example of its use: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 offailAfter
, aTestCanceledException
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:The code passed via the by-name parameter to
failAfter
orcancelAfter
will be executed by the thread that invokedfailAfter
orcancelAfter
, so that no synchronization is necessary to access variables declared outside the by-name.The
failAfter
orcancelAfter
method will create a timer that runs on a different thread than the thread that invokedfailAfter
orcancelAfter
, 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, thefailAfter
andcancelAfter
methods accept an implicit third parameter of typeSignaler
that is responsible for signaling the main thread.Configuring
failAfter
orcancelAfter
with aSignaler
The
Signaler
companion object declares an implicitval
of typeSignaler
that returns aDoNotSignal
. This serves as the default signaling strategy. If you wish to use a different strategy, you can declare an implicitval
that establishes a differentSignaler
as the policy. Here's an example in which the default signaling strategy is changed toThreadSignaler
, which does not attempt to interrupt the main thread in any way:As with the default
Signaler
, the above code will eventually produce aTestFailedDueToTimeoutException
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
andcancelAfter
: it will throw aTestFailedDueToTimeoutException
(orTestCanceledException
in case ofcancelAfter
) 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:Signaler
implementationinterrupt
on the main test thread. This will set the interrupted status for the main test thread and, if the main thread is blocked, will in some cases cause the main thread to complete abruptly with anInterruptedException
.wakeup
on the passedjava.nio.channels.Selector
, which will cause the main thread, if blocked inSelector.select
, to complete abruptly with aClosedSelectorException
.close
on thejava.io.Socket
, which will cause the main thread, if blocked in a read or write of anjava.io.InputStream
orjava.io.OutputStream
that uses theSocket
, to complete abruptly with aSocketException
.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 aSignaler
that sets that flag so that the next time around, the loop would exit.