Kotlin Exceptions and Error Handling

try {
    val n = "abc".toInt()
    println(n)
} catch (e: NumberFormatException) {
    println("Not a number: ${e.message}")
} finally {
    println("Done")
}

• Code that might fail goes in try.
• catch (e: Type) handles that kind of exception; e.message describes it.
• You can have several catch blocks. Put specific types first and general ones, such as Exception, last.
• finally always runs, whether or not an exception happened, which makes it the place for clean-up.

Because try is an expression, the value of the last line in the try or the catch becomes the result:

val age: Int = try {
    input.toInt()
} catch (e: NumberFormatException) {
    0
}

This often removes the need for a var that's assigned in each branch. For simple parsing, though, input.toIntOrNull() ?: 0 is shorter still, which is why Kotlin's OrNull functions are so popular.

Throw an exception with throw:

class InsufficientFundsException(val shortBy: Double) :
    Exception("Insufficient funds: short by £$shortBy")

if (amount > balance) throw InsufficientFundsException(amount - balance)

Kotlin's standard library has shortcuts for common checks:

• require(cond) { "msg" } throws IllegalArgumentException: use it to check arguments.
• check(cond) { "msg" } throws IllegalStateException: use it to check an object's state.
• error("msg") throws IllegalStateException immediately.

runCatching { } runs a block and wraps the outcome in a Result: either a success holding the value or a failure holding the exception. You then decide what to do without a try-catch block:

val price = runCatching { text.toDouble() }.getOrElse { 0.0 }
val result = runCatching { loadProfile(id) }
result.onSuccess { show(it) }.onFailure { println("Failed: ${it.message}") }

getOrNull() gives null on failure. To close files and other resources safely, even when an exception happens, use .use { }, as the files lesson shows.

Exceptions form a family tree, and a catch block also catches every exception below the type it names. The ones you'll meet most often:

NumberFormatException is a kind of IllegalArgumentException, which in turn is a kind of RuntimeException, so catch (e: IllegalArgumentException) also catches a failed toInt().

Unlike Java, Kotlin has no checked exceptions. The compiler never forces you to catch or declare anything, even for file errors. That keeps code short, but it means you have to think about which failures are likely and handle them where it makes sense.

When a low-level error should become a clearer, higher-level one, pass the original exception as the cause. The message explains what your code was trying to do, and the cause keeps the technical detail for debugging:

class ConfigException(message: String, cause: Throwable? = null) :
    Exception(message, cause)

fun readPort(text: String): Int =
    try {
        text.toInt()
    } catch (e: NumberFormatException) {
        throw ConfigException("Bad port: $text", e)
    }

Calling readPort("80a") throws a ConfigException with the message "Bad port: 80a", and its cause is the original NumberFormatException, whose message is For input string: "80a". Stack traces print both, so nothing is lost.

One detail about finally: it runs even when the try block returns early, but its value is ignored. In val x = try { 5 } finally { 10 }, x is 5. Keep finally for clean-up, never for producing a result.