Timeout with withTimeout in Kotlin

Introduction

Sometimes, you want to stop a task if it takes too long. withTimeout helps you do that easily.

You want to cancel a slow network request after 5 seconds.

You want to stop a long calculation if it exceeds a time limit.

You want to avoid freezing your app by limiting how long a task runs.

You want to retry a task only if it finishes quickly.

You want to make sure a background job does not run forever.

Syntax

Kotlin

withTimeout(timeMillis) {
    // code block to run with timeout
}

timeMillis is the maximum time in milliseconds to wait.

If the block takes longer, it throws TimeoutCancellationException.

Examples

Runs the code block and cancels if it takes more than 1 second.

Kotlin

withTimeout(1000) {
    println("This runs within 1 second")
}

Shows how to catch the timeout exception when the block takes too long.

Kotlin

try {
    withTimeout(500) {
        delay(1000)
    }
} catch (e: TimeoutCancellationException) {
    println("Timeout happened!")
}

Sample Program

This program tries to do 5 tasks, each taking 300ms. The total time is 1500ms, but the timeout is 1000ms, so it stops early and prints a timeout message.

Kotlin

import kotlinx.coroutines.*

fun main() = runBlocking {
    try {
        withTimeout(1000) {
            repeat(5) { i ->
                println("Working on task $i...")
                delay(300) // simulate work
            }
        }
    } catch (e: TimeoutCancellationException) {
        println("Task timed out!")
    }
}

Important Notes

Use withTimeout inside a coroutine or suspend function.

The timeout exception can be caught to handle the timeout gracefully.

Use withTimeoutOrNull if you want to get null instead of an exception on timeout.

Summary

withTimeout stops a block if it runs too long.

It throws an exception you can catch to handle timeouts.

Great for keeping your app responsive and avoiding long waits.

Practice

1. What does the Kotlin function withTimeout do?

easy

A. It cancels all running coroutines immediately.

B. It repeats a block of code until a timeout occurs.

C. It stops a block of code if it runs longer than the specified time.

D. It delays the execution of a block for a fixed time.

Solution

1. Step 1: Understand the purpose of withTimeout

   withTimeout is designed to stop a block of code if it exceeds a given time limit.

2. Step 2: Compare options with the definition

   Only "It stops a block of code if it runs longer than the specified time." correctly describes this behavior. Other options describe different coroutine behaviors.

3. Final Answer:

   It stops a block of code if it runs longer than the specified time. -> Option C

4. Quick Check:

   withTimeout stops code after time limit [OK]

Hint: Remember: withTimeout interrupts long-running code [OK]

Common Mistakes:

• Confusing withTimeout with delay function
• Thinking it repeats code instead of stopping
• Assuming it cancels all coroutines globally

2. Which of the following is the correct syntax to use withTimeout in Kotlin?

easy

A. withTimeout(1000) { /* code block */ }

B. withTimeout { 1000, /* code block */ }

C. withTimeout[1000] { /* code block */ }

D. withTimeout: 1000 { /* code block */ }

Solution

1. Step 1: Recall the function signature

   The correct syntax uses parentheses with the timeout in milliseconds as the first argument, followed by a lambda block.

2. Step 2: Match options with correct syntax

   withTimeout(1000) { /* code block */ } matches this pattern exactly. Others use incorrect brackets or misplaced arguments.

3. Final Answer:

   withTimeout(1000) { /* code block */ } -> Option A

4. Quick Check:

   withTimeout uses parentheses for timeout [OK]

Hint: Use parentheses with timeout value before code block [OK]

Common Mistakes:

• Using square brackets instead of parentheses
• Placing timeout inside the block instead of argument
• Using colon instead of parentheses

3. What will be the output of this Kotlin code?

import kotlinx.coroutines.*

fun main() = runBlocking {
    try {
        withTimeout(100) {
            repeat(5) { i ->
                println("Processing $i")
                delay(50)
            }
        }
    } catch (e: TimeoutCancellationException) {
        println("Timeout occurred")
    }
}

medium

A. Processing 0
Processing 1
Processing 2
Processing 3
Processing 4

B. Processing 0
Processing 1
Timeout occurred

C. Timeout occurred

D. Processing 0
Timeout occurred
Processing 1

Solution

1. Step 1: Analyze the timing of the loop and timeout

   Each iteration delays 50ms. After two iterations, 100ms timeout is reached.

2. Step 2: Determine output before timeout

   "Processing 0" and "Processing 1" print before timeout triggers. Then exception is caught and "Timeout occurred" prints.

3. Final Answer:

   Processing 0 Processing 1 Timeout occurred -> Option B

4. Quick Check:

   Timeout stops after 2 prints + exception message [OK]

Hint: Multiply delay by iterations to compare with timeout [OK]

Common Mistakes:

• Assuming all iterations print before timeout
• Ignoring exception catch block
• Thinking timeout cancels immediately without partial output

4. Identify the error in this Kotlin code using withTimeout:

import kotlinx.coroutines.*

fun main() = runBlocking {
    withTimeout(100) {
        delay(200)
        println("Done")
    }
}

medium

A. TimeoutCancellationException is thrown because delay exceeds timeout.

B. Syntax error: withTimeout requires a try-catch block.

C. No error; code runs and prints "Done" after 200ms.

D. Delay function cannot be used inside withTimeout.

Solution

1. Step 1: Understand withTimeout behavior with delay

   The delay of 200ms exceeds the 100ms timeout, causing a TimeoutCancellationException.

2. Step 2: Check error handling

   No try-catch is present, so exception will be thrown and program will crash.

3. Final Answer:

   TimeoutCancellationException is thrown because delay exceeds timeout. -> Option A

4. Quick Check:

   Delay longer than timeout causes exception [OK]

Hint: Delay longer than timeout causes exception unless caught [OK]

Common Mistakes:

• Assuming code waits full delay then prints
• Thinking try-catch is mandatory syntax
• Believing delay can't be used inside withTimeout

5. You want to run a network request that should timeout after 500ms. Which Kotlin code correctly uses withTimeout to achieve this and handle timeout gracefully?

hard

A. try {
networkRequest()
withTimeout(500)
} catch (e: TimeoutCancellationException) {
println("Request timed out")
}

B. withTimeout(500) {
try {
networkRequest()
} catch (e: TimeoutCancellationException) {
println("Request timed out")
}
}

C. withTimeoutOrNull(500) {
networkRequest()
} ?: println("Request timed out")

D. try {
withTimeout(500) {
networkRequest()
}
} catch (e: TimeoutCancellationException) {
println("Request timed out")
}

Solution

1. Step 1: Understand correct placement of withTimeout and try-catch

   The timeout should wrap the networkRequest call, and the exception should be caught outside to handle timeout.

2. Step 2: Evaluate options for proper structure

   try { withTimeout(500) { networkRequest() } } catch (e: TimeoutCancellationException) { println("Request timed out") } correctly wraps networkRequest inside withTimeout and catches the exception outside. withTimeout(500) { try { networkRequest() } catch (e: TimeoutCancellationException) { println("Request timed out") } } catches inside, which won't catch timeout. withTimeoutOrNull(500) { networkRequest() } ?: println("Request timed out") uses withTimeoutOrNull (valid but different). try { networkRequest() withTimeout(500) } catch (e: TimeoutCancellationException) { println("Request timed out") } misplaces withTimeout after networkRequest.

3. Final Answer:

   try { withTimeout(500) { networkRequest() } } catch (e: TimeoutCancellationException) { println("Request timed out") } -> Option D

4. Quick Check:

   Wrap withTimeout around call, catch outside [OK]

Hint: Wrap withTimeout around call, catch exception outside [OK]

Common Mistakes:

• Catching exception inside withTimeout block
• Placing withTimeout after the call
• Confusing withTimeout with withTimeoutOrNull