Multiple catch blocks in Kotlin - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to catch an exception of type ArithmeticException.

Kotlin

try {
    val result = 10 / 0
} catch (e: [1]) {
    println("Cannot divide by zero")
}

Drag options to blanks, or click blank then click option'

AArithmeticException

BIllegalArgumentException

CNullPointerException

DIOException

Attempts:

3 left

💡 Hint

Common Mistakes

Using IOException instead of ArithmeticException

Catching NullPointerException which is unrelated here

The code catches an ArithmeticException which occurs when dividing by zero.

2fill in blank

medium

Complete the code to catch a NullPointerException.

Kotlin

val text: String? = null
try {
    println(text!!.length)
} catch (e: [1]) {
    println("Null value encountered")
}

Drag options to blanks, or click blank then click option'

AIndexOutOfBoundsException

BArithmeticException

CIOException

DNullPointerException

Attempts:

3 left

💡 Hint

Common Mistakes

Using ArithmeticException which is unrelated

Catching IOException which does not occur here

The code throws a NullPointerException when trying to access length of a null string.

3fill in blank

hard

Fix the error in the catch block to handle IndexOutOfBoundsException.

Kotlin

val list = listOf(1, 2, 3)
try {
    println(list[5])
} catch (e: [1]) {
    println("Index is out of range")
}

Drag options to blanks, or click blank then click option'

AIndexOutOfBoundsException

BArithmeticException

CNullPointerException

DIllegalArgumentException

Attempts:

3 left

💡 Hint

Common Mistakes

Using NullPointerException which is unrelated

Catching ArithmeticException which does not occur here

Accessing an invalid index throws IndexOutOfBoundsException.

4fill in blank

hard

Fill both blanks to catch ArithmeticException and NullPointerException separately.

Kotlin

try {
    val number = 10 / 0
    val text: String? = null
    println(text!!.length)
} catch (e: [1]) {
    println("Arithmetic error occurred")
} catch (e: [2]) {
    println("Null pointer error occurred")
}

Drag options to blanks, or click blank then click option'

AArithmeticException

BIOException

CNullPointerException

DIndexOutOfBoundsException

Attempts:

3 left

💡 Hint

Common Mistakes

Swapping the exception types

Using unrelated exceptions like IOException

The first catch handles ArithmeticException and the second handles NullPointerException.

5fill in blank

hard

Fill all three blanks to catch ArithmeticException, NullPointerException, and IndexOutOfBoundsException in separate catch blocks.

Kotlin

try {
    val result = 10 / 0
    val text: String? = null
    println(text!!.length)
    val list = listOf(1, 2, 3)
    println(list[5])
} catch (e: [1]) {
    println("Arithmetic error")
} catch (e: [2]) {
    println("Null pointer error")
} catch (e: [3]) {
    println("Index out of bounds error")
}

Drag options to blanks, or click blank then click option'

AArithmeticException

BNullPointerException

CIndexOutOfBoundsException

DIOException

Attempts:

3 left

💡 Hint

Common Mistakes

Using IOException which is unrelated

Mixing up the order of exceptions

Each catch block handles a specific exception: ArithmeticException, NullPointerException, and IndexOutOfBoundsException.

Practice

1. What is the main purpose of using multiple catch blocks in Kotlin?

easy

A. To avoid using the try keyword

B. To run multiple try blocks at once

C. To handle different types of exceptions separately

D. To make the program run faster

Solution

1. Step 1: Understand exception handling

   Multiple catch blocks allow handling different exceptions in different ways.

2. Step 2: Compare options

   Only To handle different types of exceptions separately correctly describes handling different exception types separately.

3. Final Answer:

   To handle different types of exceptions separately -> Option C

4. Quick Check:

   Multiple catch blocks = handle exceptions separately [OK]

Hint: Remember: each catch handles one exception type [OK]

Common Mistakes:

• Thinking multiple catch blocks run in parallel
• Believing catch blocks replace try
• Assuming multiple catch blocks speed up code

2. Which of the following is the correct syntax for multiple catch blocks in Kotlin?

easy

A. try { /* code */ } catch (e: IOException) { } catch (e: Exception) { }

B. try { /* code */ } catch IOException { } catch Exception { }

C. try { /* code */ } catch e: IOException { } catch e: Exception { }

D. try { /* code */ } catch (IOException e) { } catch (Exception e) { }

Solution

1. Step 1: Recall Kotlin catch syntax

   Kotlin requires parentheses around the exception variable and type, like catch (e: Exception).

2. Step 2: Check each option

   Only try { /* code */ } catch (e: IOException) { } catch (e: Exception) { } uses correct Kotlin syntax with parentheses and colon for type.

3. Final Answer:

   try { /* code */ } catch (e: IOException) { } catch (e: Exception) { } -> Option A

4. Quick Check:

   Kotlin catch syntax = catch (e: Type) [OK]

Hint: Use parentheses and colon for exception type in catch [OK]

Common Mistakes:

• Omitting parentheses in catch
• Using Java-style catch syntax
• Missing colon between variable and type

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

try {
  val num = "abc".toInt()
} catch (e: NumberFormatException) {
  println("Number format error")
} catch (e: Exception) {
  println("General error")
}

medium

A. Compilation error

B. General error

C. No output

D. Number format error

Solution

1. Step 1: Identify exception thrown

   Calling "abc".toInt() throws NumberFormatException.

2. Step 2: Match catch block

   The first catch block matches NumberFormatException, so it runs and prints "Number format error".

3. Final Answer:

   Number format error -> Option D

4. Quick Check:

   NumberFormatException caught first = prints message [OK]

Hint: Specific exceptions catch before general ones [OK]

Common Mistakes:

• Assuming general catch runs first
• Thinking no exception occurs
• Confusing exception types

4. Find the error in this Kotlin code snippet:

try {
  val list = listOf(1, 2, 3)
  println(list[5])
} catch (e: Exception) {
  println("Error caught")
} catch (e: IndexOutOfBoundsException) {
  println("Index error")
}

medium

A. Missing finally block

B. Catch blocks are in wrong order; specific exception should come first

C. Index 5 is valid, no exception thrown

D. Try block syntax is incorrect

Solution

1. Step 1: Understand catch block order

   Specific exceptions must come before general ones to be reachable.

2. Step 2: Analyze given order

   The general Exception catch is before IndexOutOfBoundsException, so the latter is unreachable, causing a compile error.

3. Final Answer:

   Catch blocks are in wrong order; specific exception should come first -> Option B

4. Quick Check:

   Specific catch before general catch [OK]

Hint: Put specific exceptions before general ones [OK]

Common Mistakes:

• Placing general catch before specific catch
• Ignoring unreachable catch block error
• Assuming finally is mandatory

5. You want to handle FileNotFoundException and IOException differently in Kotlin. Which catch block order is correct?

try {
  // file operations
} catch (e: IOException) {
  println("IO error")
} catch (e: FileNotFoundException) {
  println("File not found")
}

hard

A. Swap catch blocks: FileNotFoundException first, then IOException

B. This order is correct; IOException first, then FileNotFoundException

C. Combine both exceptions in one catch block

D. Remove catch blocks and use only finally

Solution

1. Step 1: Understand exception hierarchy

   FileNotFoundException is a subclass of IOException.

2. Step 2: Determine catch order

   The specific subclass FileNotFoundException must be caught before the general IOException to avoid unreachable code.

3. Final Answer:

   Swap catch blocks: FileNotFoundException first, then IOException -> Option A

4. Quick Check:

   Subclass catch before superclass catch [OK]

Hint: Catch subclasses before superclasses [OK]

Common Mistakes:

• Catching superclass before subclass
• Combining unrelated exceptions incorrectly
• Skipping specific exception handling