加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 综合聚焦 > 服务器 > 安全 > 正文

为什么Scala没有检查和未检查异常的概念?

发布时间:2020-12-16 18:25:44 所属栏目:安全 来源:网络整理
导读:我有以下两个问题: 为什么Scala没有Checked和Un-checked异常的概念? 不支持检查异常有哪些优缺点? 解决方法 TL; DR跳到最后一段:) 虽然我完全赞同蒂亚戈的答案,但有一些事情可以补充. 如您所知,Scala是一种功能性和面向对象的语言. 它的功能方面规定应该
我有以下两个问题:

>为什么Scala没有Checked和Un-checked异常的概念?
>不支持检查异常有哪些优缺点?

解决方法

TL; DR跳到最后一段:)
虽然我完全赞同蒂亚戈的答案,但有一些事情可以补充.
如您所知,Scala是一种功能性和面向对象的语言.
它的功能方面规定应该消除 side-effects,或者至少尽可能地减少最小化.抛出异常是一种副作用,因为它不是引用透明的(即,它取决于抛出异常的上下文,例如,如果从try块内部抛出异常,它将被捕获,而如果它是抛出那个try块之外,它会改变程序的流程).
以下是Scala中的函数式编程一书中的一个例子(P. Chiusano,R.Bjarnason)

def failingFn(i: Int): Int = {
       val y: Int = throw new Exception("fail!")
       try {
         val x = 42 + 5
         x + y
       }
       catch { case e: Exception => 43 }
 }

在上面的代码中,y不是引用透明的,因为如果用try块中的值替换它,函数的结果将是不同的.
好吧,对于所有的理论来说,从上面得到的关键是,抛出异常是一种副作用,这违反了函数式编程范式.为了解决这个问题,Scala的设计者决定返回“值”,表示发生了异常,而不是抛出异常.出于这个原因,引入了类似Try(及其直接子类型成功和失败)的类.您只需修改函数的返回类型,将其包装在Try中,而不是抛出异常.这会强制客户端检查成功或失败,而不会产生抛出异常带来的所有副作用. Try类型的引入基本上替换了已检查的异常,因为通过使用Try返回类型,客户端在编译时隐式地意识到异常的可能性.

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读