Java自定义异常,应该继承Exception还是Runtime Exception,为什么?

回答1:

继承Exception还是继承RuntimeException是由异常本身的特点决定的,而不是由是否是自定义的异常决定的。

例如我要写一个java api,这个api中会调用一个极其操蛋的远端服务,这个远端服务经常超时和不可用。所以我决定以抛出自定义异常的形式向所有调用这个api的开发人员周知这一操蛋的现实,让他们在调用这个api时务必考虑到远端服务不可用时应该执行的补偿逻辑(比如尝试调用另一个api)。此时自定义的异常类就应继承Exception,这样其他开发人员在调用这个api时就会收到编译器大大的红色报错:【你没处理这个异常!】,强迫他们处理。

又如,我要写另一个api,这个api会访问一个非常非常稳定的远端服务,除非有人把远端服务的机房炸了,否则这个服务不会出现不可用的情况。而且即便万一这种情况发生了,api的调用者除了记录和提示错误之外也没有别的事情好做。但出于某种不可描述的蛋疼原因,我还是决定要定义一个异常对象描述“机房被炸”这一情况,那么此时定义的异常类就应继承RuntimeException,因为我的api的调用者们没必要了解这一细微的细节,把这一异常交给统一的异常处理层去处理就好了。

回答2:

直接看规范吧 Chapter 11. Exceptions

  • Exception is the superclass of all the exceptions from which ordinary programs may wish to recover.

    The class RuntimeException is a direct subclass of Exception. RuntimeException is the superclass of all the exceptions which may be thrown for many reasons during expression evaluation, but from which recovery may still be possible.

    RuntimeException and all its subclasses are, collectively, the run-time exception classes.

The unchecked exception classes are the run-time exception classes and the error classes.

The checked exception classes are all exception classes other than the unchecked exception classes. That is, the checked exception classes are Throwable and all its subclasses other than RuntimeException and its subclasses and Error and its subclasses.

规范里说明了,Java Exception分为两种, unchecked exceptionchecked exception 显然,前者是运行时异常继承自RuntimeException,后者受控异常继承自Exception。

回答3:

对抛出的异常,checked exception要与方法耦合,尤其是接口中定义的方法影响比较大,使用起来不够灵活。不抛出异常,就得满屏的try-catch。

我现在的做法是除非抛出的异常需要调用层显式处理,否则自定义异常都继承RuntimeException,在最上层的调用统一做一次try-catch。这样一来方法的声明和使用简洁了很多。

其实,我觉得最重要的还是团队的约定。

回答4:

尽量继承RuntimeException。这么做可以降低代码间的耦合性,你想,如果继承Exception(或者其它受查异常),万一原来抛出异常的那个方法不再抛出异常了呢?岂不是接口、以及所有的上层调用方法中的try-catch都得改?

而且太多受查异常很容易把代码搞乱

参考:https://www.zhihu.com/question/51970444

  • 5
    点赞
  • 9
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
目 录 第一章 JAVA入门 10 计算机语言发展史 10 机器语言 10 汇编语言 10 高级语言 10 其他高级语言 11 JAVA发展简史 12 JAVA为什么能够流行? 13 JAVA各版本的含义 13 JAVA技术体系架构 14 JAVA的特性和优势 14 JAVA应用程序的运行机制 15 JVM(JAVA VIRTUAL MACHINE) 16 Java运行时环境JRE(Java Runtime Environment) 17 JAVA语言应用范围 18 第一个JAVA程序 18 JAVA开发环境搭建 18 一个典型的JAVA程序的编写和运行过程 19 第一个程序常见错误 20 第一个JAVA程序的总结和提升 20 常用Java开发工具 20 常用dos命令 21 本章笔试作业 21 本章上机操作 21 第二章(1) 编程的基本概念 22 注释 22 标识符 22 关键字/保留字 23 变量(variable) 24 常量(Constant) 25 命名规则(规范) 25 基本数据类型(primitive data type) 26 整型变量 26 浮点型 27 字符型(2个字节): 28 boolean类型 29 运算符(operator) 29 二元运算符 29 一元运算符 30 布尔逻辑表达符 30 位运算符 30 扩展运算符 31 字符串连接符 31 三目条件运算符 31 运算符优先级的问题 31 自动类型转换 32 基本类型转化时常见错误和问题 33 方法 33 简单的键盘输入和输出 33 本章思考作业 34 上机操作 34 第二章(2) 控制语句 35 顺序结构 35 选择结构 35 if单选择结构 35 if-else双选择结构 35 If-elseif-else多选择结构 36 switch多选择结构 37 循环结构 39 While和dowhile的区别 41 For循环 42 break语句和continue语句 47 语句块 48 递归结构 49 本章作业 50 本章上机操作 51 第三章 JAVA面向对象程序开发 52 编程语言发展史 52 类和对象是如何产生发展的?如何进化的? 52 面向对象思想初步(OOP初步Object Oriented Programming) 53 面向对象编程的语言的三大特征简介 56 对象和类的概念 56 类和对象初步 57 测试类的定义方式 57 简单的学生类编写示例 58 内存分析 59 属性(field,或者叫成员变量) 59 引用类型 60 类的方法 60 对象的创建和使用 60 构造器(或者叫做构造方法,constructor) 60 垃圾回收机制(Garbage Collection) 63 方法的重载(overload),构造方法的重载 63 this关键字 65 static 关键字 66 静态初始化块(经常用来初始化类,加载类信息时执行!) 67 package 68 JDK中的主要包 68 import 68 eclipse的使用 69 继承(extend, inheritance) 70 为什么需要继承继承的作用? 70 继承介绍 70 如何实现继承? 70 继承使用要点 71 Object类 72 toString方法 72 equals方法 73 super关键字 74 方法的重写(override) 74 隐藏/封装(encapsulation) 75 为什么需要封装?封装的作用和含义? 75 使用访问控制符,实现封装 76 封装的使用细节 76 多态(polymorphism) 76 为什么需要多态? 76 如何实现多态? 77 方法绑定(method binding) 77 静态绑定 77 动态绑定 77 多态的使用要点 78 对象的转型(casting) 79 final 81 抽象类 82 抽象类的使用要点 83 接口 83 为什么需要接口? 84 如何定义接口? 84 接口的本质探讨 84 接口使用要点 85 接口的多继承 86 面向接口编程 87 OOP更多应用 87 组合 87 内部类(innerclasses) 88 字符串(java.lang.String类)的使用 90 字符串相等的判断 92 思考作业 93 上机作业 94 第四章 异常机制 95 导引问题 95 异常(Exception)的概念 96 异常分类 96 Error 97 Error和Exception的区别 97 Exception 97 异常的处理办法之一,捕获异常 99 try块 99 catch 99 finally 100 try, catch,finally ,return 执行顺序 100 异常的处理办法之二,声明异常:
异常概述 •异常处理已经成为衡量一门语言是否成熟的标准之一,目前的主流编程语言如C++、C#、Ruby、 Python等,大都提供了异常处理机制。增加了异常处理机制后的程序有更好的容错性,更加健壮。 传统错误处理的缺陷 •传统错误处理机制,主要如下两个缺点:   –无法穷举所有异常情况:因为人类知识的限制,异常情况总比可以考虑到的情况多,总有“漏网之鱼”的异常情况,所以程序总是不够健壮。   –错误处理代码和业务实现代码混杂:这种错误处理和业务实现混杂的代码严重影响程序的可读性,会增加程序维护的难度。 使用try...catch捕获异常 •执行try块里的业务逻辑代码时出现异常,系统自动生成一个异常对象,该异常对象被提交给Java运 行时环境,这个过程被称为抛出(throw)异常。 •Java运行时环境收到异常对象时,会寻找能处理该异常对象的catch块,如果找到合适的catch块并 把该异常对象交给该catch块处理,那这个过程被称为捕获(catch)异常;如果Java运行时环境找 不到捕获异常的catch块,则运行时环境终止,Java程序也将退出。 异常的捕捉流程 Java的异常体系 访问异常信息 •如果程序需要在catch块中访问异常对象的相关信息,可以通过调用catch后异常形参的方法来获 得。当Java运行时决定调用某个catch块来处理该异常对象时,会将该异常对象赋给catch块后的异 常参数,程序就可以通过该参数来获得该异常的相关信息。 •所有异常对象都包含了如下几个常用方法:   –getMessage():返回该异常的详细描述字符串。   –printStackTrace():将该异常的跟踪栈信息输出到标准错误输出。   –printStackTrace(PrintStream s):将该异常的跟踪栈信息输出到指定输出流。   –getStackTrace():返回该异常的跟踪栈信息。 异常处理 复制代码 try { 需要检测的代码; } catch(异常类 变量) { 异常处理代码; } finally { 一定会执行的代码; } 复制代码 Finally代码块只有一种情况不会被执行。就是在之前执行了System.exit(0)。 Java 7提供的多异常捕捉 •在Java 7以前,每个catch块只能捕捉一个异常。从Java 7开始,一个catch块可以捕捉多个异常。 –catch(异常1 | 异常 2 | 异常3 ex) –{ –} •多个异常之间用竖线隔开。 •多异常捕捉时,异常变量之前有隐式final修饰。 本文原创作者:pipi-changing 本文原创出处:http://www.cnblogs.com/pipi-changing/ 使用finally回收资源 •程序在try块里打开了一些物理资源(例如数据库连接、网络连接和磁盘文件等),这些物理资源都 必须显式回收。 •为了保证一定能回收try块中打开的物理资源,异常处理机制提供了finally块。不管try块中的代码是 否出现异常,也不管哪一个catch块被执行,finally块总会被执行。 异常处理的嵌套 •异常处理流程代码可以放在任何能放可执行性代码的地方,因此完整的异常处理流程既可放在try块 里,也可放在catch块里,也可放在finally块里。 •异常处理嵌套的深度没有很明确的限制,但通常没有必要使用超过两层的嵌套异常处理,层次太深的 嵌套异常处理没有太大必要,而且导致程序可读性降低。 Java 7的自动关闭资源的try语句 –try( – // 此处声明的资源, 系统可以自动关闭它。 –) –{ – // –} •对于自动关闭资源的try语句, 可以没有catch和finally——try块可以孤独地存在。 •自动关闭资源的try语句,有两个注意点:   –只有放在try后面的圆括号里的资源才会被关闭。   –能被自动关闭的资源必须实现Closeable或AutoCloseable接口。 Checked异常与Runtime异常 •Java的异常被分为两大类:Checked异常和Runtime异常(运行时异常)。所有 RuntimeException类及其子类的实例被称为Runtime异常;不是RuntimeException类及其子类 的异常实例则被称为Checked异常。 Checked异常的处理 •当前方法明确知道如何处理该异常,程序应该使用try...catch块来捕获该异常,然后在对应的catch 块中修改该异常。 •当前方法不知道如何处理这种异常,应该在定义该方法时声明抛出该异常。 Runtime异常的处理 •Runtime异常则更加灵活,Runtime异常无需显式声明抛出。 •如果程序需要捕捉Runtime异常,也可以使用try...catch块来捕捉Runtime异常。 使用throws声明抛出异常 •throws声明抛出异常的思路是:当前方法不知道应该如何这种类型的异常,该异常应该由上一级调 用者处理,如果main方法也不知道应该如何处理这种类型的异常,也可以使用throws声明抛出异 常,该异常将交给JVM处理。JVM对异常的处理方法是:打印异常跟踪栈信息,并中止程序运行,这 就是前面程序在遇到异常后自动结束的原因。 •throws声明抛出只能在方法签名中使用,throws可以声明抛出多个异常类,多个异常类之间以逗 号隔开。throws声明抛出的语法格式如下   –throws ExceptionClass1 , ExceptionClass2... 抛出异常 •如果需要在程序中自行抛出异常,应使用throw语句,throw语句可以单独使用,throw语句抛出 的不是异常类,而是一个异常实例,而且每次只能抛出一个异常实例。throw语句的语法格式如下:   –throw ExceptionInstance; •如果throw语句抛出的异常是Checked异常,则该throw语句要么处于try块里,显式捕获该异常 ,要么放在一个带throws声明抛出的方法中,即把该异常交给该方法的调用者处理。 Java 7增强的throw语句 –try –{ – new FileInputStream(“a.txt”); –} –Catch(Exception ex) –{ – ex.printStackTrace(); – throw ex; //① –} •从JDK 7开始,Java编译器可以只能地识别①号代码处抛出的异常只是FileNotFoundException异常。 自定义异常类 •程序很少会自行抛出系统异常,因为异常的类名通常包含了该异常的有用信息。所以在选择抛出什么 异常时,应该选择合适的异常类,从而可以明确地描述该异常情况。在这种情形下,应用程序常常需要 抛出自定义异常。 •用户自定义异常应该继承Exception基类,如果希望自定义Runtime异常,则应该继承 RuntimeException基类。定义异常类时通常需要提供两种构造器:一个是无参数的构造器;另一个 是带一个字符串参数的构造器,这个字符串将作为该异常对象的详细说明(也就是异常对象的 getMessage方法的返回值)。 异常链 •当业务逻辑层访问持久层出现SQLException异常时,程序不应该把底层的SQLException异常传 到用户界面,原因有如下两个:   –对于正常用户而言,他们不想看到底层SQLException,SQLException对他们使用该系统没 有任何帮助。   –对于恶意用户而言,将SQLException暴露出来是一种不安全的。 Java的异常跟踪栈 •异常对象的printStackTrace方法用于打印异常的跟踪栈信息,根据printStackTrace方法的输出 结果,我们可以找到异常的源头,并跟踪到异常一路触发的过程。 •面向对象的应用程序运行时,经常会发生一系列方法调用,从而形成“方法调用栈”,异常的传播则与 相反:只要异常没有被完全捕获(包括异常没有被捕获,或异常被处理后重新抛出了新异常),异常从 发生异常的方法逐渐向外传播,首先传给该方法的调用者,该方法调用者再次传给其调用者……直至最 后传到 main方法,如果main方法依然没有处理该异常,JVM会中止该程序,并打印异常的跟踪栈信 息。 异常处理规则 •不要过度使用异常 •不要使用过于庞大的try块 •避免使用Catch All语句 •不要忽略捕获到异常 。。。。。。。。。。。。。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值