Exceptions & Error Handling

What you'll learn

Things go wrong — bad input, missing files, network failures. Kotlin handles errors with exceptions, but with a modern twist: all exceptions are unchecked, and Kotlin offers functional alternatives (Result, sealed classes) that often read better.

By the end you'll be able to:

• Understand why Kotlin exceptions are all unchecked
• Use try/catch as an expression
• Handle failure functionally with runCatching and Result
• Model expected errors with sealed classes

All exceptions are unchecked

In Java, checked exceptions force you to declare or catch them, which many find cumbersome. Kotlin made a deliberate choice: every exception is unchecked. There's no throws clause and no compiler requirement to handle anything. You catch what you can meaningfully recover from, and let the rest propagate.

try as an expression

Like if and when, try/catch is an expression in Kotlin — it returns a value. And throw is an expression too (of type Nothing), so it slots into an Elvis or a when branch:

fun parseAge(input: String): Int {
    return try {
        input.toInt()
    } catch (e: NumberFormatException) {
        -1                    // try/catch is an EXPRESSION — it returns a value
    }
}

println(parseAge("25"))   // 25
println(parseAge("abc"))  // -1

val age = 20

val category = when {
    age < 0  -> throw IllegalArgumentException("Age can't be negative")
    age < 18 -> "minor"
    else     -> "adult"
}
println(category)   // adult

runCatching & Result

For a functional approach, runCatching { ... } runs a block and captures success or failure in a Result object — no try/catch needed. You then extract the value with getOrDefault, getOrNull, or handle both cases with fold:

val good = runCatching { "42".toInt() }
println(good.isSuccess)          // true
println(good.getOrDefault(0))    // 42

val bad = runCatching { "abc".toInt() }
println(bad.getOrDefault(-1))    // -1  (recovered, no crash)

Modeling errors with sealed classes

For expected outcomes (a validation failure, a not-found), exceptions are often the wrong tool — they're for the exceptional. A cleaner approach models success and failure as a sealed class (Module 18), so the compiler forces callers to handle every case with an exhaustive when:

sealed class LoadResult
data class Ok(val data: String) : LoadResult()
data class Fail(val error: String) : LoadResult()

fun load(id: Int): LoadResult =
    if (id > 0) Ok("Item $id") else Fail("Invalid id")

when (val r = load(5)) {
    is Ok -> println("Loaded: ${r.data}")
    is Fail -> println("Error: ${r.error}")
}

Recap & quick check

Great — your programs fail gracefully now. Next up: Module 27 — Annotations & Reflection.