Multiple catch blocks in Kotlin - Step-by-Step Execution

Concept Flow - Multiple catch blocks

Try block starts

↓

Code runs

↓

Exception occurs?

No→Try block ends normally

Yes↓

Check first catch block type

↓

Matches

↓

Run catch

↓

Catch block ends

↓

Continue after try-catch

The program tries code in the try block. If an exception happens, it checks each catch block in order to find a matching type. The first matching catch runs. If none match, the exception is unhandled.

Execution Sample

Kotlin

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

This code tries to convert a string to an integer. It catches NumberFormatException first, then any other Exception.

Execution Table

Step	Action	Exception Thrown?	Catch Block Checked	Catch Block Matches?	Output
1	Enter try block, execute "abc".toInt()	Yes: NumberFormatException	NumberFormatException catch	Yes	Number format error
2	Catch block executed	No	N/A	N/A	Number format error printed
3	Try-catch ends, continue program	No	N/A	N/A	No further output

💡 Exception caught by first matching catch block; program continues normally.

Variable Tracker

Variable	Start	After Step 1	After Step 2	Final
num	undefined	Exception thrown, no value assigned	N/A	N/A
e	undefined	Exception object created	Catch block variable assigned	Out of scope after catch

Key Moments - 2 Insights

Why does the first catch block run instead of the second?

Because the exception thrown is NumberFormatException, which matches the first catch block type exactly, so Kotlin runs that catch block and skips the others (see execution_table step 1).

What happens if no catch block matches the exception?

If no catch block matches, the exception is unhandled and will crash the program or propagate up (not shown in this example). The execution_table shows a matching catch, so no crash occurs here.

Visual Quiz - 3 Questions

Look at the execution table, which catch block handles the exception?

A No catch block handles it

B The second catch block for Exception

C The first catch block for NumberFormatException

D Both catch blocks handle it

💡 Hint

Check the 'Catch Block Matches?' column in step 1 of the execution_table.

At which step does the program print "Number format error"?

A Step 1

B Step 2

C Step 3

D It never prints

💡 Hint

Look at the 'Output' column in steps 1 and 2 of the execution_table.

If the first catch block was removed, which catch block would handle the exception?

A The second catch block for Exception

B A new catch block would be needed

C No catch block would handle it

D The program would not compile

💡 Hint

Refer to the catch block order and matching logic in the concept_flow and execution_table.

Concept Snapshot

try {
  // code that might throw
} catch (e: ExceptionType1) {
  // handle ExceptionType1
} catch (e: ExceptionType2) {
  // handle ExceptionType2
}

- Kotlin checks catch blocks in order.
- First matching catch runs.
- If none match, exception is unhandled.

Full Transcript

This example shows how Kotlin handles multiple catch blocks. The try block runs code that throws a NumberFormatException. Kotlin checks the first catch block, which matches this exception type, so it runs that catch block and prints "Number format error". The second catch block is skipped. After handling, the program continues normally. If no catch block matched, the exception would be unhandled and could crash the program. This flow helps manage different error types separately.

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