转载

从Kotlin协程的实战看 kotlin与java 在异常处理上的不同（Checked Exception）

kotlin-jvm 这套东西上的协程其实就是个线程框架。与go 语言那种高性能的协程是有本质不同的，千万不要被迷惑了。除了阿里巴巴自己魔改的jvm以外，目前没有哪家jvm可以实现类似于go语言的那种协程能力。

kotlin中的suspend 关键字是什么作用？

他最大的作用就是如果你在某个方法前面加了suspend 那么这个方法的执行就会要求一个线程的执行上下文环境，否则会编译不通过。

从Kotlin协程的实战看 kotlin与java 在异常处理上的不同（Checked Exception）

看上图中的例子，被suspend 标识的io1 方法，如果没有指定线程的执行环境那么ide报红直接编译不过，但是如果你指定了他的线程上下文环境则是可以编译通过的。

这里要注意的是如果你用suspend方法标记的函数函数体内部并没有使用协程关键字用来切线程的话，那在编译的时候 suspend其实就没作用了，这里看图也可以知道 suspend在ide中显示成了灰色。

此外，所谓的kotlin协程的挂起就是指切了个线程去干活，仅此而已。

kotlin-jvm 平台的协程到底有啥用？

其实就是方便给我们切线程使用的，假设我们有一个需求是简单的从本地sd卡上请求一个数据然后显示在ui上

纯java版本的

new Thread()
        {
            @Override
            public void run() {
                try {
                    Thread.sleep(3000);
                } catch (InterruptedException e) {

                }

                runOnUiThread(new Runnable() {
                    @Override
                    public void run() {
                        mGoodsTitle.setText("adasdasda");
                    }
                });

            }
        }.start();

复制代码

如果这个需求再复杂一点，比如需要你显示在ui上以后再去网络请求个什么东西然后接口回来再刷新ui。这一套如果用原生的java来写，可想而知会很麻烦，而且代码会有很多回调。可读性也不好。

但是如果用Rxjava来写，则会简单很多

subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
复制代码

我们可以用 rxjava提供的这些操作符来方便的切换我们的线程，代码可读性会变的非常好。

有人要问了，那还需要kotlin的协程干啥？

kotlin的协程在处理类似代码的时候会更加智能， 他的线程切走了以后是可以自动切回来的 不需要你再手动的指定你的代码执行线程了。

举个例子：

GlobalScope.launch(Dispatchers.Main) {
            withContext(Dispatchers.IO) {
                //do io sth
            }
            textview.text = " do ui sth"

            withContext(Dispatchers.IO) {
                //do io sth2
            }
            textview.text = " do ui sth2"
        }

复制代码

这里就是典型的kotlin的协程应用场景。我们先指定了一个线程执行上下文的环境是main 也就是主线程。

然后我们用协程的关键字 withContext 来切到io线程执行我们的工作，这个时候后面的代码是不会走的。

一定会等到withContext里面的代码执行完毕以后，才会走到 textview.text = " do ui sth" 这里。

然后后面我们又执行了 withContext(Dispatchers.IO) 一次，这时最后一行的textview.text 也是不会走的。

他一定会等到上面的协程执行完毕以后才会走。

所以这里你好好体会下是不是会觉得这种写法比rxjava还要方便？毕竟线程切走以后再切回来这个操作 kotlin协程帮我们做好了，再也不需要手动执行线程了这个就是kotlin 协程的最大作用了。

其余的什么协程速度快啊之类的话都是吹牛逼的。至少在kotlin-jvm上是不对的。

使用协程会内存泄露吗？

当然会，因为协程前面我们说过了，本质上就是个线程。所以线程会导致activity内存泄露的场景在协程中一样存在。其实这里如果有rxjava 编程经验的同学应该大概知道怎么做了。这里rxjava的写法我就不多写了，写一下协程的吧。

首先定义一个scope

var scope= MainScope();
复制代码

然后稍微改变一下我们的写法注意这次不是global scope了是我们刚才定义的scope了

scope.launch(Dispatchers.Main) {
            withContext(Dispatchers.IO) {
                //do io sth
            }
            textview.text = " do ui sth"

            withContext(Dispatchers.IO) {
                //do io sth2
            }
            textview.text = " do ui sth2"
        }

复制代码

然后在这里释放即可。

override fun onDestroy() {
        scope.cancel()
        super.onDestroy()
    }
复制代码

跟Rxjava十分的像。就是换了个写法而已。当然你如果还使用了lifecycle

那就更加简单了

lifecycleScope.launch {  }
复制代码

这样释放的时候我们连cancel 都可以省略了，全部交给谷歌提供的lifecycleScope就可以了。

最后提一下 coroutineScope 这个函数也相当有用，可以限制我们的协程执行环境，有兴趣的同学可以自行搜索一下，这里不再展开。

delay函数比thread的sleep函数更加高效？

纯扯淡的说法，什么delay 不阻塞线程， sleep阻塞线程都是纯扯淡的说法，不要信。

本质上就是kotlin的delay函数就是个协程，delay的本质就是切了个线程然后在那个线程里面 sleep 了一段时间，结束以后再切回来，仅此而已。

如果你自己读懂了我上面的文章那么看到这个delay函数前面的suspend 其实你就知道是啥意思了。

retrofit支持kotlin了以后写起来很简单？

确实很简单。可以看一下之前的写法：

这是java版本的：

我们看下kotlin协程版本的：

但是这里要注意了，这里有个大坑，kotlin是一个不强制异常处理检查的语言，所以这里的异常是会抛出来的！一定要注意，一旦网络请求有了诸如404 或者502的异常你上面的代码就直接crush了。

其实想想也能想明白你看我这个简写的写法甚至都没有地方可以处理onFailure 里面的流程，那万一发生了 onFailure里面的情况怎么办？怎么把这些错误信息抛给你？也只有异常了。

看下retrofit的源码

一目了然。

所以使用retrofit+kotlin的时候一定要谨记主动捕获异常,一方面是为了程序不要crush 另外一方面也是为了处理程序中的异常情况

GlobalScope.launch(Dispatchers.Main) {
            val reposItem = try {
                retrofit.create(GitHubService::class.java)
                    .allRepositories2(page, "pushed:<" + Date().format("yyyy-MM-dd"), 10)
            } catch (e: Exception) {
                Log.v(
                    "wuyue",
                    "e:" + (e is HttpException) + "  e:" + e.message + "   e:" + (e is Throwable)
                );
            }
            Log.v("wuyue", "reposItem2222222==$reposItem")
        }
复制代码

kotlin 与 java 在ce上的不同？

对于java 来说，如果你在方法内部 throw了一个Exception 那你必须在方法签名的地方主动用throws标记这个异常并且在调用的时候主动捕获，否则编译就会不通过。

看到没这里是编译不过的。

改成这样就可以了。

调用的地方也是：

必须try catch 否则也是编译不过的。

但是要注意噢，如果是 RuntimeException 则不会出现上面的情况，如果你在方法体内部 throw 一个

RuntimeException ，那你方法签名的地方不写throws 也是可以编译通过的。调用的地方啥都不干不写try catch 也没问题。这里一定要注意。

最后就是坑爹的kotlin语言，不管你在方法里面 throw的是 RuntimeException 还是Exception 他都让你编译通过。。。

这就会导致如果你调用一个函数，如果里面throw了一个异常，然后函数的注释或者文档又没告诉你这里可能会抛异常的话，那这个地方可能就会发生可怕的事情了，对于客户端来说就是crush。目前我不知道kotlin为啥要这样设计，但是大家在调用kotlin的函数的时候最好还是多点进去看看，看看到底会不会抛异常，免的搞出线上事故。

原文 https://juejin.im/post/5eaa3afde51d454de8289cdb

正文到此结束