打造稳健的 Android 应用：协程异常处理的实用策略

异常处理是保障应用稳健性的基石，在不同开发环境中，异常的表现与处理方式大相径庭。本文将带您解码Java、Android与Kotlin协程中的异常行为差异，剖析常见陷阱，并最终提供一套构建坚不可摧应用的最佳实践与"避坑指南"。

---

Java 与 Android 异常处理的区别

Java 异常处理

在 Java 中，异常是局限于发生异常的线程的。如果子线程抛出未捕获的异常，它不会影响主线程或其他线程。主线程可以继续正常运行，即使子线程遇到错误。

示例：

public class JavaThreadExample {
    public static void main(String[] args) {
        try {
            new Thread(() -> {
                throw new RuntimeException("Exception in child thread");
            }).start();
        } catch (Exception e) {
            System.out.println("Caught exception: " + e.getMessage());
        }
        System.out.println("Main thread continues...");
    }
}

输出： 子线程中的异常不会被主线程的 try-catch 捕获，主线程继续执行。

---

Android 异常处理

在 Android 中，异常处理更加严格。如果子线程抛出未捕获的异常，整个应用会崩溃。这是因为未捕获的异常会传播到主进程级别，导致应用终止。Android 的这种机制旨在确保应用的稳定性。

关键点： 在 Android 中，异常必须在发生的线程内捕获。如果未捕获异常，应用将崩溃。

示例：

fun thread1() {
    try {
        thread {
            Thread.sleep(2000)
            throw Exception("Exception inside thread")
        }
    } catch (e: Exception) {
        Log.e("test", e.message.toString())
    }
}

结果： 线程内部的异常无法被外部的 try-catch 捕获，必须在线程内部处理。

---

Kotlin 协程中的异常处理

Kotlin 协程引入了一种新的并发编程范式，与线程类似，协程中的异常局限于发生异常的协程。外部的 try-catch 无法捕获协程内部抛出的异常。

示例：

suspend fun launch1() = coroutineScope {
    try {
        launch {
            delay(2000)
            1 / 0 // 抛出异常
        }
    } catch (e: Exception) {
        Log.e("test", e.message.toString())
    }
}

结果： 协程内部的异常无法被外部的 try-catch 捕获，必须在协程内部处理。

---

coroutineScope 与 supervisorScope 的区别

在使用协程时，理解 coroutineScope 和 supervisorScope 的区别对于有效的异常处理至关重要。

coroutineScope

在 coroutineScope 中，如果一个子协程失败，会取消所有其他兄弟协程。这种行为确保错误能够一致地传播和处理，但可能导致意外的取消。

示例：

private suspend fun exampleCoroutineScope2() = coroutineScope {
    launch {
        try {
            delay(1000)
            Log.e("test", "Child 1 completed")
        } catch (e: Exception) {
            Log.e("test", "Child 1 failed: ${e.message}")
        }
    }
    launch {
        try {
            delay(500)
            throw Exception("Child 2 failed")
        } catch (e: Exception) {
            Log.e("test", "Child 2 failed: ${e.message}")
        }
    }
    launch {
        try {
            delay(1500)
            Log.e("test", "Child 3 completed")
        } catch (e: Exception) {
            Log.e("test", "Child 3 failed: ${e.message}")
        }
    }
}

结果： 如果 Child 2 失败，所有其他兄弟协程（Child 1 和 Child 3）都会被取消。

---

supervisorScope

在 supervisorScope 中，兄弟协程是相互独立的。如果一个协程失败，它不会影响其他协程的执行。这在需要隔离错误并确保其他任务能够继续时非常有用。

示例：

suspend fun exampleSupervisorScope2() = supervisorScope {
    launch {
        try {
            delay(1000)
            Log.e("test", "Child 1 completed")
        } catch (e: Exception) {
            Log.e("test", "Child 1 failed: ${e.message}")
        }
    }
    launch {
        try {
            delay(500)
            throw Exception("Child 2 failed")
        } catch (e: Exception) {
            Log.e("test", "Child 2 failed: ${e.message}")
        }
    }
    launch {
        try {
            delay(1500)
            Log.e("test", "Child 3 completed")
        } catch (e: Exception) {
            Log.e("test", "Child 3 failed: ${e.message}")
        }
    }
}

结果： 如果 Child 2 失败，Child 1 和 Child 3 不会受到影响，继续执行。

---

如果异常在repo处理，coroutineScope 和 supervisorScope 的区别会消失

在实际开发中，如果我们将异常处理集中在仓库层（Repository Layer），那么 coroutineScope 和 supervisorScope 的区别就会变得不那么重要。因为仓库层会捕获所有与数据相关的异常（如网络错误或数据库错误），并将其转化为可控的结果返回给上层（如 ViewModel 或 UI 层）。这样，无论是 coroutineScope 还是 supervisorScope，都不会因为未捕获的异常导致协程取消或传播。

示例：

suspend fun fetchData() = try {
    repository.getData() // 在仓库层处理异常
} catch (e: Exception) {
    Log.e("test", "Error in repository: ${e.message}")
    null // 返回一个安全的结果
}

通过这种方式，协程的异常处理逻辑被集中管理，减少了代码的复杂性，同时提高了应用的稳定性。

---

CoroutineExceptionHandler 的挑战

虽然 CoroutineExceptionHandler 提供了一种处理协程中未捕获异常的机制，但它也存在一些局限性。主要问题在于每次启动协程时都需要显式传递 CoroutineExceptionHandler，这会导致代码冗长且不够优雅。

为什么不推荐过度使用 CoroutineExceptionHandler？

1. 复杂性： 在多个应用层中管理 CoroutineExceptionHandler 会导致代码分散且难以维护。
2. 分层架构： 更好的做法是将异常处理集中在仓库层（Repository Layer），在这里可以统一管理与数据相关的错误（如网络错误或数据库错误）。这样可以确保异常不会传播到更高的层级（如 ViewModel 或 UI 层）。

---

异常处理的最佳实践

在repo处理异常

将异常处理集中在仓库层，确保与数据相关的错误能够得到有效管理。这种方法提高了代码的可维护性，同时让更高层级（如 ViewModel 和 UI 层）专注于自己的职责。

总结

在 Java、Android 和 Kotlin 协程中，异常处理的机制和行为各不相同。通过遵循最佳实践（如在仓库层集中处理异常、使用 supervisorScope 处理独立任务、在协程内部捕获异常），可以构建健壮且易于维护的应用。如果异常处理集中在仓库层，那么 coroutineScope 和 supervisorScope 的区别将变得不那么重要，因为异常已经被统一管理，协程的取消和传播逻辑不会影响应用的稳定性。理解这些细微差别将帮助开发者避免常见问题，确保应用在面对意外错误时能够保持稳定和弹性。