发现不一样的Kotlin多方位处理协程的异常

发现不一样的Kotlin多方位处理协程的异常_第1张图片

Kotlin 中的协程已经成为在网络请求中比较常用的一种方式,除了正常请求外,我们同样需要处理请求中的异常情况,本篇文章将处理协程中的异常分为以下几个部分:

一、try-catch

1.1 try-catch基础使用
1.2 什么情况下try-catch会无效?
1.3 什么是协程的结构化并发?

二、CoroutineExceptionHandler

2.1 CoroutineExceptionHandler的介绍
2.2 CoroutineExceptionHandler的使用
2.3 CoroutineExceptionHandler的不足
三、SupervisorScope+async
四、结论

一、try-catch捕获异常

1.1 try-catch基础使用

一般来说,处理异常可以使用try-catch块,在try中编写请求代码,catch负责捕获异常。

以一个普通的请求为例:

Api接口:

interface ProjectApi {
    @GET("project/tree/json")
    suspend fun loadProjectTree(): BaseResp>

    @GET("project/tree/jsonError")
    suspend fun loadProjectTreeError(): BaseResp>
}

Api接口里面列出了两个接口,一个loadProjectTree()作为能够请求成功的接口,loadProjectTreeError()则故意在path中多加了’Error’,模拟请求失败的状态。

具体调用:

suspend fun loadProjectTree() {
        try {
            val result = service.loadProjectTree()
            val errorResult = service.loadProjectTreeError()
            Log.d(TAG, "loadProjectTree: $result")
            Log.d(TAG, "loadProjectTree errorResult: $errorResult")
        } catch (e: Exception) {
            Log.d(TAG, "loadProjectTree: Exception  " + e.message)
            e.printStackTrace()
        }
    }

我们看调用后的结果:

loadProjectTree: Exception HTTP 404 Not Found

由于故意将loadProjectTreeError接口中的path写错,执行流程理所当然的走进了catch里,报了404的错误。loadProjectTree和loadProjectTreeError两个接口其实一个是成功,一个是失败,但当两个接口放在同一个trycatch块中,只要有一个失败,另外的请求即使是成功的,也不再执行。

如果我们想要彼此接口不影响,则需要为每个接口单独设立try-catch块。如下:

 suspend fun loadProjectTree() {
        try {
            val errorResult = service.loadProjectTreeError()
            Log.d(TAG, "loadProjectTree errorResult: $errorResult")
        } catch (e: Exception) {
            Log.d(TAG, "loadProjectTree: error Exception  " + e.message)
            e.printStackTrace()
        }

        try {
            val result = service.loadProjectTree()
            Log.d(TAG, "loadProjectTree: $result")
        } catch (e: Exception) {
            Log.d(TAG, "loadProjectTree: Exception  " + e.message)
            e.printStackTrace()
        }
    }

我们将loadProjectTreeError和loadProjectTree分别使用try-catch块进行异常捕获,运行结果也正如预期,接口请求互相不影响:

loadProjectTree: error Exception HTTP 404 Not Found
loadProjectTree: com.fuusy.common.network.BaseResp@57e153d

上述为一般状况下处理协程异常的方法,但是在某些情况下,try-catch却也存在捕获不到异常的可能。

1.2 什么情况下try-catch会无效?

正常来说,try-catch块中只有代码块存在异常,都将被捕获到catch中。但是协程中的异常却存在特殊情况。

例如在协程中开启一个失败的子协程,则无法捕获。还是以上面的接口举个例子:

     fun loadProjectTree() {
        viewModelScope.launch() {
            try {
                //子协程
                launch {
                    //失败的接口
                    service.loadProjectTreeError()
                }
            } catch (e: Exception) {
                e.printStackTrace()
            }

        }
    }

在try-catch块中创建了一个子协程,调用了一个百分百会失败的接口,这个时候我们期望的是能将异常捕获至catch中,但是真正运行后却发现App崩溃退出了。这也验证了try-catch作用无效

至于try-catch为什么在协程中开启一个失败的子协程的情况下会失败?这就不得不提到一个新的知识点,协程的结构化并发

1.3 什么是协程的结构化并发?

在kotlin的协程中,全局的GlobalScope是一个作用域,每个协程自身也是一个作用域,新建的协程与它的父作用域存在一个级联的关系,也就是一个父子关系层次结构。而这级联关系主要在于:

  1. 父作用域的生命周期持续到所有子作用域执行完;

  2. 当结束父作用域结束时,同时结束它的各个子作用域;

  3. 子作用域未捕获到的异常将不会被重新抛出,而是一级一级向父作用域传递,这种异常传播将导致父父作用域失败,进而导致其子作用域的所有请求被取消。

上面的三点也就是协程结构化并发的特性。

了解了什么是协程的结构化并发,那我们就又回到try-catch为什么在协程中开启一个失败的子协程的情况下会失败?的问题上。很显然,上面第3点就是这个问题的答案,子协程中未捕获的异常不会被重新抛出,而是在父子层次结构中向上传播,这种异常传播将导致父Job失败。

在这种情况下,我们就应该使用一个新的处理异常的方法:CoroutineExceptionHandler

二、CoroutineExceptionHandler全局捕获异常

除了try-catch外,协程处理异常的第二个方法是使用CoroutineExceptionHandler

2.1 CoroutineExceptionHandler的介绍

首先我们来了解一下什么是CoroutineExceptionHandler

CoroutineExceptionHandler是用于全局“捕获所有”行为的最后一种机制。您无法在CoroutineExceptionHandler中从异常中恢复。当处理程序被调用时,协程已经完成了相应的异常。通常,该处理程序用于记录异常、显示某种错误消息、终止和/或重新启动应用程序。

这是官方文档中对CoroutineExceptionHandler的解释,起初时我对于这个解释是读不懂的,后面仔细想了想,CoroutineExceptionHandler作为一个全局捕获异常的方式,是由于协程结构化并发的特性的存在,子作用域的异常经过一级一级的传递,最后由CoroutineExceptionHandler进行处理。因为传递到CoroutineExceptionHandler时已经到达顶层作用域,这种情况下,子协程已经结束。也就是说在CoroutineExceptionHandler被调用时,所有子协程已经完成了相应的异常。

2.2 CoroutineExceptionHandler的使用

首先,我们在ViewModel中创建了一个exceptionHandler

    private val exceptionHandler = CoroutineExceptionHandler { _, exception ->
        Log.d(TAG, "CoroutineExceptionHandler exception : ${exception.message}")
    }

接着将exceptionHandler附加给viewModelScope。

    fun loadProjectTree() {
        viewModelScope.launch(exceptionHandler) {
            //失败的接口
            service.loadProjectTreeError()
        }
    }

根据协程的结构化并发的特性,当根协程通过launch{}启动时,异常将被传递给已附加的CoroutineExceptionHandler

2.3 CoroutineExceptionHandler的不足

协程中不使用try-catch,CoroutineExceptionHandler作为全局捕获异常的机制,最后异常会在CoroutineExceptionHandler中处理。但是有两点需要注意:

  1. 由于没有try-catch来捕获住异常,异常会向上传播,直到它到达RootScope或SupervisorJob,根据协程的结构化并发的特性,异常向上传播时,父协程会失败,同时父协程所级联的子协程和兄弟协程也都会失败;

如果你想并行请求多个接口,并且需要他们彼此不影响任务的执行,也就是任何一个接口异常,其他任务将继续执行,那么CoroutineExceptionHandler不是一个很好的选择。而接下来说的supervisorScope更适合这种情况。

  1. CoroutineExceptionHandler的作用在于全局捕获异常,CoroutineExceptionHandler无法在代码的特定部分处理异常,例如针对某一个失败接口,无法在异常后进行重试或者其他特定操作。

如果你想在特定部分做异常处理的话,try-catch更适合。

三、SupervisorScope+async

上面2.3提到了CoroutineExceptionHandler的一个缺陷:子协程出现异常,父协程和其兄弟协程也都会跟着执行失败。

针对此问题,kotlin协程中提出了另一个协程作用域:SupervisorScope

该作用域与async结合开启协程时,子协程出现了异常,并不会影响其父协程以及其兄弟协程。所以更适合多个并行任务的执行。

举个例子:

viewModelScope.launch() {
            supervisorScope {
                try {
                    //除数为0,抛异常
                    val deferredFail = async { 2 / 0 }
                    //成功
                    val deferred = async {
                        2 / 1
                        Log.d(TAG, "loadProjectTree:  2/1 ")
                    }
                    deferredFail.await()
                    deferred.await()

                } catch (e: Exception) {
                    Log.d(TAG, "loadProjectTree:Exception ${e.message} ")
                }
            }
        }

在supervisorScope作用域里包裹这两个除法运算,一个除数为0,必定会抛出一个异常,另一个则模拟成功状态,使用async分别开启一个协程,运行后的结果如下:

从结果上看,除数为0时,抛出了异常,同时另外一个兄弟协程也能够正常运行

四、结论

  • 在代码的特定部分处理异常,可使用try-catch;
  • 全局捕获异常,并且其中一个任务异常,其他任务不执行,可使用CoroutineExceptionHandler,节省资源消耗;
  • 并行任务间互不干扰,任何一个任务失败,其他任务照常运行,可使用SupervisorScope+async模式。

最后

我整理一些Android 开发相关的学习文档、面试题,希望能帮助到大家学习提升,如有需要参考的可以点击链接领取哦点击这里免费领取

发现不一样的Kotlin多方位处理协程的异常_第2张图片

发现不一样的Kotlin多方位处理协程的异常_第3张图片

你可能感兴趣的:(Android,安卓,Android,Kotiln,移动开发)