异常是面向对象语言非常重要的一个特性,良好的异常设计对程序的可扩展性、可维护性、健壮性都起到至关重要。
JAVA根据用处的不同,定义了两类异常
* Checked Exception: Exception的子类,方法签名上需要显示的声明throws,编译器迫使调用者处理这类异常或者声明throws继续往上抛。
* Unchecked Exception: RuntimeException的子类,方法签名不需要声明throws,编译器也不会强制调用者处理该类异常。
异常的作用和好处:
1. 分离错误代码和正常代码,代码更简洁。
2. 保护数据的正确性和完整性,程序更严谨。
3. 便于调试和排错,软件更好维护。
……
相信很多JAVA开发人员都看到或听到过“不要使用异常来控制流程”,虽然这句话非常易于记忆,但是它并未给出“流程”的定义,所以很难理解作者的本意,让人迷惑不解。
如果“流程”是包括程序的每一步执行,我认为异常就是用来控制流程的,它就是用来区分程序的正常流程和错误流程,为了更能明确的表达意思,上面这 句话应改成“不要用异常来控制程序的正常流程”。现在带来一个新的问题就是如何区分程序正常流程和异常流程?我实在想不出一个评判标准,就举例来说明,大 家思维扩散下。
为了后面更方便的表达,我把异常分成两类,不妥之处请谅解
* 系统异常:软件的缺陷,客户端对此类异常是无能为力的,通常都是Unchecked Exception。
*业务异常:用户未按正常流程操作导致的异常,都是Checked Exception
金币转帐例子
1. 需求规定金币一次的转账范围是1~500,如果超过这个额度,就要提示用户金额超出单笔转账的限制,转账的金额是由用户在页面输入的:
因为值是用户输入的,所以给的值超出限定的范围肯定是司空见惯。我们当然不能把它(输入的值超出限定的范围)归结于异常流程,它应该属于正常流程,应该提供验证数据的完整功能。
正确的实现如下:
提供一个判断转账金币数量是否超出限定范围的方法
- private static final int MAX_PRE_TRANSFER_COIN = 500;
- public boolean isCoinExceedTransferLimits(int coin) {
- return coin > MAX_PRE_TRANSFER_COIN;
- }
Action里先对值进行校验,若不合法,直接返回并提示用户
2. 在转账的过程里,发些金币数量不够:
我们的程序都是运行在并发环境中,Action无法完全做到判断金币是否足够。因为在判断之后和事务之前的刹那间,有可能产生其他扣费操作导致金币不够。这时我们就需要用业务异常(Checked Exception)来控制
正确的实现如下
CoinNotEnoughExcetion .java
- //金币不够的异常类
- public class CoinNotEnoughExcetion extends Exception {
- private static final long serialVersionUID = -7867713004171563795L;
- private int coin;
- public CoinNotEnoughExcetion() {
- }
- public CoinNotEnoughExcetion(int coin) {
- this.coin = coin;
- }
- public int getCoin() {
- return coin;
- }
- @Override
- public String getMessage() {
- return coin + " is exceed transfer limit:500";
- }
- }
//转账方法
- private static final int MAX_PRE_TRANSFER_COIN = 500;
- public void transferCoin(int coin) throws CoinNotEnoughExcetion{
- if (!hasEnoughCoin())
- throw new CoinNotEnoughExcetion(coin);
- // do transfering coin
- }
3. 接口transferCoin(int coin)的规范里已经定了契约,调用transferCoin之前必须要先调用isCoinExceedTransferLimits判断值是否合法:
虽然规范人人都要遵循,但毕竟只是规范,编译器无法强制约束。此时就需要用系统异常(Unchecked Exception,用JDK的标准异常)来保证程序的正确性,没遵守规范的都当做软件bug处理。
正确的实现如下:
//转账方法
- public void transferCoin(int coin){
- if (coin > MAX_PRE_TRANSFER_COIN)
- throw new IllegalArgumentException(coin+" is exceed tranfer limits:500");
- // do transfering coin
- }
至此,举例已经结束了,在这里再延伸下—业务异常和系统异常类在实现上的区别,该区别的根源来自于调用者捕获到异常后是如何处理的
Action对业务异常的处理:操作具体的异常类
- public String execute() {
- try {
- userService.transferCoin(coin);
- } catch (CoinExceedTransferLimitExcetion e) {
- e.getCoin();
- }
- return SUCCESS;
- }
Action对系统异常的处理:无法知道具体的异常类
- public String execute() {
- try {
- userService.transferCoin(coin);
- } catch (RuntimeException e) {
- LOG.error(e.getMessage());
- }
- return SUCCESS;
- }
调用者捕获业务异常(Checked Excetion)之后,通常不会去调用getMessage()方法的,而是调用异常类里特有的方法,所以业务异常类的实现要注重特有的,跟业务相关的方法,而不是getMessage()方法。
系统异常类恰恰相反,捕获者只会调用getMessage()获取异常信息,然后记录错误日志,所以系统异常类(Uncheck Exception)的实现类对getMessage()方法返回内容比较讲究。
不管是业务异常还是系统异常,都需要提供丰富的信息。如:数据库访问异常,需要提供查询sql语句等;HTTP接口调用异常,需要给出访问的URL和参数列表(如果是post请求,参数列表不提供也可以,取决于维护人员或者开发人员拿到参数列表会如何去使用)。
1. Sql语法错误异常类(取自spring框架的异常类,Spring的异常体系很强大,值得一看):
- public class BadSqlGrammarException extends InvalidDataAccessResourceUsageException {
- private String sql;
- public BadSqlGrammarException(String task, String sql, SQLException ex) {
- super(task + "; bad SQL grammar [" + sql + "]", ex);
- this.sql = sql;
- }
- public SQLException getSQLException() {
- return (SQLException) getCause();
- }
- public String getSql() {
- return this.sql;
- }
- }
2. HTTP接口调用异常类
- public class HttpInvokeException extends RuntimeException {
- private static final long serialVersionUID = -6477873547070785173L;
- public HttpInvokeException(String url, String message) {
- super("http interface unavailable [" + url + "];" + message);
- }
- }
如何选择用Unchecked Exception和Checked Exception
1.是软件bug还是业务异常,软件bug是Unchecked Exception,否则是Checked Exception
2.如果把该异常抛给用户,用户能否做出补救。如果客户端无能为力,则用Unchecked Exception,否则抛Checked Exception
结合这两点,两类异常就不会混淆使用了。
异常设计的几个原则:
1.如果方法遭遇了一个无法处理的意外情况,那么抛出一个异常。
2.避免使用异常来指出可以视为方法的常用功能的情况。
3.如果发现客户违反了契约(例如,传入非法输入参数),那么抛出非检查型异常。
4.如果方法无法履型契约,那么抛出检查型异常,也可以抛出非检查型异常。
5.如果你认为客户程序员需要有意识地采取措施,那么抛出检查型异常。
6.异常类应该给客户提供丰富的信息,异常类跟其它类一样,允许定义自己的属性和方法。
7.异常类名和方法遵循JAVA类名规范和方法名规范
8.跟JAVA其它类一样,不要定义多余的方法和变量。(不会使用的变量,就不要定义,spring的BadSqlGrammarException.getSql() 就是多余的)
以下是我工作当中碰到的一些我认为不是很好的写法,我之前也犯过此类的错误
A. 整个业务层只定义了一个异常类
- public class ServiceException extends RuntimeException {
- private static final long serialVersionUID = 8670135969660230761L;
- public ServiceException(Exception e) {
- super(e);
- }
- public ServiceException(String message) {
- super(message);
- }
- }
理由:
1.业务异常不应该是Unchecked Exception。
2.不存在一个具体的异常类名称是“ServiceException”。
解决方法:定义一个抽象的业务异常“ServiceException”
- public abstract class ServiceException extends Exception {
- private static final long serialVersionUID = -8411541817140551506L;
- }
B. 忽略异常
- try {
- new String(source.getBytes("UTF-8"), "GBK");
- } catch (UnsupportedEncodingException e) {
- e.printStackTrace();
- }
理由:
1.环境不支持UTF-8或者GBK很显然是一个非常严重的bug,不能置之不理
2.堆栈的方式记录错误信息不合理,若产品环境是不记录标准输出,这个错误信息就会丢失掉。若产品环境是记录标准输出,万一这段程序被while循环的线程调用,有可能引起硬盘容量溢出,最终导致程序的运行不正常,甚至数据的丢失。
解决方法:捕获UnsupportedEncodingException,封装成Unchecked Exception,往上抛,中断程序的执行。
- try {
- new String(source.getBytes("UTF-8"), "GBK");
- } catch (UnsupportedEncodingException e) {
- throw new IllegalStateException("the base runtime environment does not support 'UTF-8' or 'GBK'");
- }
C. 捕获顶层的异常—Exception
- public void transferCoin(int outUid, int inUserUid, int coin) throws CoinNotEnoughException {
- final User outUser = userDao.getUser(outUid);
- final User inUser = userDao.getUser(inUserUid);
- outUser.decreaseCoin(coin);
- inUser.increaseCoin(coin);
- try {
- // BEGIN TRANSACTION
- userDao.save(outUser);
- userDao.save(inUser);
- // END TRANSACTION
- // log transfer operate
- } catch (Exception e) {
- throw new ServiceException(e);
- }
- }
理由:
1. Service并不是只能抛出业务异常,Service也可以抛出其他异常
如IllegalArgumentException、ArrayIndexOutOfBoundsException或者spring框架的DataAccessException
2. 多数情况下,Dao不会抛Checked Exception给Service,假如所有代码都非常规范,Service类里不应该出现try{}catch代码。
解决方法:删除try{}catch代码
- public void transferCoin(int outUid, int inUserUid, int coin) throws CoinNotEnoughException {
- final User outUser = userDao.getUser(outUid);
- final User inUser = userDao.getUser(inUserUid);
- outUser.decreaseCoin(coin);
- inUser.increaseCoin(coin);
- // BEGIN TRANSACTION
- userDao.save(outUser);
- userDao.save(inUser);
- // END TRANSACTION
- // log transfer operate
- }
D. 创建没有意义的异常
- public class DuplicateUsernameException extends Exception {
- }
理由
1. 它除了有一个"意义明确"的名字以外没有任何有用的信息了。不要忘记Exception跟其他的Java类一样,客户端可以调用其中的方法来得到更多的信息。
解决方案:定义上捕获者需要用到的信息
- public class DuplicateUsernameException extends Exception {
- private static final long serialVersionUID = -6113064394525919823L;
- private String username = null;
- private String[] availableNames = new String[0];
- public DuplicateUsernameException(String username) {
- this.username = username;
- }
- public DuplicateUsernameException(String username, String[] availableNames) {
- this(username);
- this.availableNames = availableNames;
- }
- public String requestedUsername() {
- return this.username;
- }
- public String[] availableNames() {
- return this.availableNames;
- }
- }
E. 把展示给用户的信息直接放在异常信息里。
- public class CoinNotEnoughException2 extends Exception {
- private static final long serialVersionUID = 4724424650547006411L;
- public CoinNotEnoughException2(String message) {
- super(message);
- }
- }
- public void decreaseCoin(int forTransferCoin) throws CoinNotEnoughException2 {
- if (this.coin < forTransferCoin)
- throw new CoinNotEnoughException2("金币数量不够");
- this.coin -= forTransferCoin;
- }
理由:展示给用户错误提示信息属于文案范畴,文案易变动,最好不要跟程序混淆一起。
解决方法:
错误提示的文案统一放在一个配置文件里,根据异常类型获取对应的错误提示信息,若需要支持国际化还可以提供多个语言的版本。
F. 方法签名声明了多余的throws
理由:代码不够精简,调用者不得不加上try{}catch代码
解决方案:若方法不可能会抛出该异常,那就删除多余的throws
G. 给每一个异常类都定义一个不会用到ErrorCode
理由:多一个功能就多一个维护成本
解决方法:不要无谓的定义ErrorCode,除非真的需要(如给别人提供接口调用的,这时,最好对异常进行规划和分类。如1xx代表金币相关的异常,2xx代表用户相关的异常…
最后推荐几篇关于异常设计原则
1.异常设计
http://www.cnblogs.com/JavaVillage/articles/384483.html(翻译)
http://www.javaworld.com/jw-07-1998/jw-07-techniques.html(原文)
2. 异常处理最佳实践
http://tech.e800.com.cn/articles/2009/79/1247105040929_1.html(翻译)
http://onjava.com/pub/a/onjava/2003/11/19/exceptions.html(原文)
相关推荐
为了深入理解和正确实施这一机制,本文将阐述有效处理Java异常的三个重要原则,并结合JCheckbook类的示例进行讨论。 首先,Java中的异常是由Throwable类的层次结构所定义的,其中包含了Error、Exception以及...
8. **异常设计原则** - **异常应该具有明确的语义**:异常的命名和类型应清楚地表明它代表的错误情况。 - **避免在finally块中抛出异常**:这可能导致原始异常被覆盖,丢失重要信息。 - **不要滥用异常**:异常不...
Java 异常的基本概念和语法开始,讲述 Java 异常处理的基本知识,分析 Java 异常体系结构,对比 Spring 的异常处理框架,阐述异常处理的基本原则,并提出了自己处理一个大型应用系统异常的思想,并通过设计一个异常...
本资料“Java并发编程设计原则和模式”深入探讨了如何在Java环境中有效地进行并发处理,以充分利用系统资源并避免潜在的并发问题。 一、并发编程基础 并发是指两个或多个操作在同一时间段内执行,但并不意味着这些...
在进行Java异常处理设计时,我们需要遵循以下原则: 1. **不要直接忽略异常**:捕获到的异常应当被适当处理,无论是记录日志、通知用户还是尝试恢复。忽略异常可能会导致程序行为不可预测,甚至导致程序崩溃。 2. ...
以下是基于给定内容总结的Java异常处理的设计原则: 1. **早处理**:异常不应该用于控制正常程序流程,而应该仅用于处理非预期的情况。一旦发生异常,应尽早捕获并处理,避免异常向上冒泡到程序的更高层次。如果不...
《Java并发编程:设计原则与模式(第二版)》是一本深入探讨Java多线程编程技术的权威著作。这本书详细阐述了在Java平台中进行高效并发处理的关键概念、设计原则和实用模式。以下是对该书内容的一些核心知识点的概述...
本书的核心目的是帮助新手程序员理解和掌握这些设计原则和最佳实践,从而提升他们的编程水平和思维方式。下面将详细讨论Java程序设计中的关键知识点。 1. **面向对象编程(OOP)**:Java是一种面向对象的语言,其...
Java异常处理机制研究的知识点涵盖了异常处理的基本概念、分类、原则以及实际应用等方面。 1. 异常处理概念 异常处理是Java语言中用于处理程序运行时遇到的错误和异常情况的一种机制。它通过异常类的层次结构来实现...
本资源"Java并发编程_设计原则和模式(CHM)"聚焦于Java语言在并发环境下的编程技巧、设计原则以及最佳实践模式。 一、并发编程基础 并发编程涉及多个执行单元同时运行,这些单元可能是线程或进程。在Java中,主要...
遵循SOLID原则,编写可读性强、可维护的代码,以及了解如何利用设计模式解决常见问题,都是成为一个优秀Java程序员的必备素养。 总的来说,天津大学的这门Java程序设计课件涵盖了从基础知识到进阶主题的全面内容,...
本文将详细介绍 Java 异常处理机制的应用研究,包括 Java 异常体系统结构、异常分类与处理机制、异常处理的一般原则和异常处理框架等。 Java 异常体系统结构 Java 异常体系统结构如图 1 所示,Throwable 是所有...
Java异常体系是基于面向对象的设计,使得错误处理更加结构化和可维护。以下是Java异常的一些主要类别和相关知识点: 1. **算术异常**:`ArithmeticException` - 当发生违反算术规则的操作时,例如整数除以零,会抛...
清晰的注释、合理的命名、有效的代码复用以及遵循SOLID原则的类设计,都是提高代码质量和可维护性的关键。 通过这个Java程序设计课程设计,学生不仅能提升编程技能,还能锻炼解决问题的能力,为未来的职业生涯打下...
在本次的JAVA课程设计中,学生们被要求实现一个基本的记事本程序,这是一项常见的实践任务,旨在加深对Java编程语言的理解,并提升面向对象编程、事件处理以及GUI(图形用户界面)设计的能力。这份“JAVA课程设计...
Java 异常处理原则是指在处理异常时需要遵守的一些基本原则,如尽量少地抛出异常、合理地使用 finally 块、避免 catch-all 异常、使用多 catch 块等。 五、Java 异常处理机制的应用 Java 异常处理机制的应用非常...
1. **设计原则**:遵循SOLID原则(单一职责原则、开闭原则、里氏替换原则、接口隔离原则和依赖倒置原则),这有助于创建稳定、可复用的API。此外,还包括DRY(Don't Repeat Yourself)原则,避免重复代码。 2. **...
2. **异常不应用于流程控制**:异常设计的目的是处理程序运行中的意外情况,而不是作为常规的流程控制手段。使用if语句进行条件判断通常更有效率且更清晰。 3. **区分稳定代码和非稳定代码**:在catch块中,应将...