Error handling patterns in Android Kotlin - Deep Dive

Overview - Error handling patterns

What is it?

Error handling patterns are ways to manage problems that happen when an app runs. They help the app respond to unexpected situations like missing data or network failures without crashing. These patterns guide how to detect, report, and recover from errors smoothly. They make apps more reliable and user-friendly.

Why it matters

Without good error handling, apps can crash or behave unpredictably, frustrating users and causing data loss. Error handling patterns help developers write code that anticipates problems and deals with them gracefully. This improves user trust and app quality, making the difference between a buggy app and a polished experience.

Where it fits

Before learning error handling patterns, you should understand Kotlin basics, functions, and exceptions. After this, you can explore advanced topics like coroutines error handling, reactive streams error management, and custom error reporting systems.

Mental Model

Core Idea

Error handling patterns are structured ways to catch and manage problems so the app stays stable and user-friendly.

Think of it like...

It's like having a safety net under a tightrope walker; if they slip, the net catches them so they don't fall hard.

┌───────────────┐
│  Normal Flow  │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│   Error?      │
├──────┬────────┤
│ Yes  │  No    │
▼      ▼        ▼
┌───────────┐  ┌───────────────┐
│ Handle    │  │ Continue Flow │
│ Error     │  └───────────────┘
└───────────┘

Build-Up - 7 Steps

1

Foundation

What is an error in apps

Concept: Errors are unexpected problems that happen when the app runs, like missing files or bad input.

In Kotlin, errors often show as exceptions, which stop normal code unless caught. For example, trying to open a file that doesn't exist throws an exception.

Result

Recognizing errors helps you prepare your app to handle them instead of crashing.

Understanding what errors are is the first step to managing them and keeping your app stable.

2

Foundation

Basic try-catch blocks

Concept: Try-catch blocks let you run code that might fail and catch errors to handle them.

Use try { /* risky code */ } catch (e: Exception) { /* handle error */ } to prevent crashes. For example: try { val data = readFile("file.txt") } catch (e: java.io.IOException) { println("File not found") }

Result

The app catches the error and can show a message instead of crashing.

Try-catch is the simplest way to catch errors and keep your app running.

3

Intermediate

Using sealed classes for error results

🤔Before reading on: do you think returning errors as values or throwing exceptions is better for app flow? Commit to your answer.

Concept: Instead of throwing exceptions, functions can return a sealed class representing success or error, making error handling explicit.

Define a sealed class Result with Success and Error subclasses. Functions return Result. Example: sealed class Result { data class Success(val data: T): Result() data class Error(val message: String): Result() } fun loadData(): Result { return try { Result.Success("Data") } catch (e: Exception) { Result.Error("Failed") } }

Result

Callers check if result is Success or Error and handle accordingly without exceptions.

Returning error states as values makes error handling clear and avoids hidden crashes.

4

Intermediate

Handling errors with Kotlin's runCatching

🤔Before reading on: do you think runCatching simplifies try-catch or adds complexity? Commit to your answer.

Concept: runCatching is a Kotlin function that wraps code and captures exceptions, returning a Result object.

Use runCatching { /* code */ } which returns Result. You can then use onSuccess and onFailure to handle outcomes: val result = runCatching { riskyOperation() } result.onSuccess { println("Success") } .onFailure { println("Error: ${it.message}") }

Result

Cleaner code that separates success and error handling without explicit try-catch blocks.

runCatching provides a concise way to handle errors as values, improving readability.

5

Intermediate

Error handling in asynchronous code

🤔Before reading on: do you think errors in coroutines are caught the same way as in normal code? Commit to your answer.

Concept: Errors in coroutines need special handling because they run asynchronously and can crash the app if uncaught.

Use try-catch inside suspend functions or CoroutineExceptionHandler to catch errors globally. Example: val handler = CoroutineExceptionHandler { _, exception -> println("Caught $exception") } GlobalScope.launch(handler) { throw Exception("Oops") }

Result

Errors in coroutines are caught and handled without crashing the app.

Knowing coroutine error handling prevents silent crashes in asynchronous code.

6

Advanced

Custom error types and propagation

🤔Before reading on: do you think all errors should be generic exceptions or specific types? Commit to your answer.

Concept: Creating custom error classes helps identify and handle different error cases precisely.

Define custom exceptions or error sealed classes for your app's domain. Propagate errors up or convert them to user-friendly messages. Example: class NetworkError(val code: Int): Exception() fun fetch() { throw NetworkError(404) } try { fetch() } catch (e: NetworkError) { println("Network error code: ${e.code}") }

Result

More precise error handling and better user feedback.

Custom errors improve clarity and control over error responses in complex apps.

7

Expert

Combining error handling with functional patterns

🤔Before reading on: do you think functional error handling is harder or easier to maintain? Commit to your answer.

Concept: Using functional programming concepts like Either or Result monads can make error handling composable and predictable.

Libraries like Arrow provide Either type to chain operations that may fail without exceptions. Example: fun parseInt(str: String): Either = str.toIntOrNull()?.right() ?: "Not a number".left() val result = parseInt("123").map { it * 2 } result.fold( { error -> println("Error: $error") }, { value -> println("Value: $value") } )

Result

Error handling becomes a clear flow of success or failure, easy to combine and test.

Functional error handling reduces bugs by making error paths explicit and composable.

Under the Hood

Kotlin error handling uses exceptions that unwind the call stack until caught by a try-catch block. When using Result or sealed classes, errors are values passed explicitly, avoiding stack unwinding. Coroutines handle errors by suspending and resuming with exception handlers. Functional patterns wrap values in containers that represent success or failure, enabling chaining without exceptions.

Why designed this way?

Exceptions were designed to separate error code from normal code but can hide error paths and cause crashes if uncaught. Returning error values makes handling explicit and safer. Coroutines needed special error handling due to asynchronous execution. Functional patterns come from the need to write predictable, testable code without side effects.

┌───────────────┐
│  Function A   │
├──────┬────────┤
│ Try  │ Throws │
└──────┴────────┘
       │
       ▼
┌───────────────┐
│  Function B   │
├──────┬────────┤
│ Catch│ Handle │
└──────┴────────┘

OR

┌───────────────┐
│ Function returns│
│ Result value   │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Caller checks │
│ Result type   │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: do you think catching all exceptions globally is a good practice? Commit yes or no.

Common Belief: Catching all exceptions globally prevents all crashes and is always good.

Reality: Catching all exceptions globally can hide bugs and make debugging hard. It may also mask serious errors that should crash or be fixed.

Why it matters: Overusing global catches leads to silent failures and poor app quality.

Quick: do you think returning null is a good way to signal errors? Commit yes or no.

Common Belief: Returning null is a simple way to indicate an error or missing value.

Reality: Returning null can cause null pointer exceptions later and hides the error cause. Explicit error types or Result wrappers are safer.

Why it matters: Using null for errors leads to crashes and hard-to-find bugs.

Quick: do you think exceptions are slow and should be avoided at all costs? Commit yes or no.

Common Belief: Exceptions are slow and harm performance, so avoid them.

Reality: Exceptions have some cost but are usually negligible compared to network or disk operations. Proper use improves code clarity.

Why it matters: Avoiding exceptions unnecessarily complicates code and can reduce maintainability.

Quick: do you think errors in coroutines are caught automatically like normal code? Commit yes or no.

Common Belief: Errors in coroutines are caught automatically by the system.

Reality: Errors in coroutines must be caught explicitly with try-catch or handlers; otherwise, they crash the app silently.

Why it matters: Ignoring coroutine error handling causes unexpected app crashes.

Expert Zone

1

Custom error types can carry rich context like error codes, user messages, and recovery actions, enabling smarter error handling.

2

Combining error handling with Kotlin's sealed classes and functional patterns leads to more predictable and testable code flows.

3

CoroutineExceptionHandler only catches uncaught exceptions in coroutines; errors inside suspend functions still need local try-catch.

When NOT to use

Avoid complex functional error handling in very simple apps where it adds unnecessary complexity. For UI code, prefer user-friendly error messages over raw exceptions. Use exceptions for truly unexpected errors, but prefer Result types for expected failure cases.

Production Patterns

In production, apps use layered error handling: low-level functions return Result or throw custom exceptions, middle layers convert errors to user-friendly messages, and global handlers log errors and report crashes. Coroutines use structured concurrency with handlers to isolate failures.

Connections

Functional Programming

Error handling patterns build on functional concepts like monads and immutability.

Understanding functional error handling helps write safer, composable code in mobile apps.

User Experience Design

Error handling directly affects how users perceive app reliability and trust.

Good error handling patterns improve UX by providing clear feedback and recovery options.

Safety Nets in Construction

Both provide a fallback to prevent disaster when something goes wrong.

Seeing error handling as a safety net helps prioritize catching and managing failures early.

Common Pitfalls

#1 Ignoring exceptions and letting the app crash.

Wrong approach:

fun load() {
val data = readFile("missing.txt") // no try-catch
println(data)
}

Correct approach:

fun load() {
try {
val data = readFile("missing.txt")
println(data)
} catch (e: java.io.IOException) {
println("File missing, showing default")
}
}

Root cause:

Beginners often forget to catch exceptions, causing crashes.

#2 Using null to indicate errors instead of explicit types.

Wrong approach:

fun fetchData(): String? {
if (error) return null
return "data"
}
val result = fetchData()
println(result.length) // crashes if null

Correct approach:

sealed class Result {
data class Success(val data: String): Result()
object Error: Result()
}
fun fetchData(): Result {
if (error) return Result.Error
return Result.Success("data")
}
when(val result = fetchData()) {
is Result.Success -> println(result.data.length)
is Result.Error -> println("Error occurred")
}

Root cause:

Null hides errors and leads to null pointer exceptions.

#3 Catching all exceptions with a generic catch and ignoring them.

Wrong approach:

try {
riskyOperation()
} catch (e: Exception) {
// do nothing
}

Correct approach:

try {
riskyOperation()
} catch (e: java.io.IOException) {
println("Handle IO error")
} catch (e: Exception) {
println("Unexpected error: ${e.message}")
}

Root cause:

Ignoring exceptions hides bugs and makes debugging impossible.

Key Takeaways

Error handling patterns help apps manage problems gracefully without crashing.

Try-catch blocks are the basic tool, but returning error results makes handling clearer.

Coroutines require special error handling to avoid silent crashes in asynchronous code.

Custom error types and functional patterns improve precision and maintainability.

Misusing error handling leads to crashes, hidden bugs, or poor user experience.