“本文是Exception处理的一篇不错的文章,从Java Exception的概念介绍起,依次讲解了Exception的类型(Checked/Unchecked),Exception处理的最佳实现:
1. 选择Checked还是Unchecked的几个经典依据
2. Exception的封装问题
3. 如无必要不要创建自己得Exception
4. 不要用Exception来作流程控制
5. 不要轻易的忽略捕获的Exception
6. 不要简单地捕获顶层的Exception”
——选自JAVADigest.Net对原文的介绍
关于异常处理的一个问题就是要对何时(when)和如何(how)使用它们做到了然于心。在本文中我将介绍一些关于异常处理的最佳实践,同时我也会涉及到最近争论十分激烈的checked Exception的使用问题。
作为开发员,我们都希望能写出解决问题并且是高质量的代码。不幸的是,一些副作用(side effects)伴随着异常在我们的代码中慢慢滋生。无庸置疑,没有人喜欢副作用(side effects),所以我们很快就用我们自己的方式来避免它,我曾经看到一些聪明的程序员用下面的方式来处理异常:
public void consumeAndForgetAllExceptions(){
try {
...some code that throws exceptions
} catch (Exception ex){
ex.printStacktrace();
}
}
上边的代码有什么问题么?
在回答以前让我们想想怎样才是正确的?是的,一旦程序碰到异常,它就该挂起程序而“做”点什么。那么上边的代码是这样子的么?看吧,它隐瞒了什么?它把所有的“苦水”往肚里咽(在控制台打印出异常信息),然后一切继续,从表面上看就像什么都没有发生过一样……,很显然,上边代码达到的效果并不是我们所期望的。
后来又怎样?
public void someMethod() throws Exception{
}
上边的代码又有什么问题?
很明显,上边的方法体是空的,它不实现任何的功能(没有一句代码),试问一个空方法体能抛出什么异常?当然Java并不阻止你这么干。最近,我也遇到类似的情景,方法声明会抛出异常,但是代码中并没有任何“机会”来“展示”异常。当我问开发员为什么要这样做的时候,他回答我说“我知道,它确实有点那个,但我以前就是这么干的并且它确实能为我工作。”
在C++社区曾经花了数年实践来实践如何使用异常,关于此类的争论在java社区才刚刚开始。我曾经看到许多Java程序员针对使用异常的问题进行争论。如果对于异常处理不当的话,异常可以大大减慢应用程序的执行速度,因为它将消耗内存和CPU来创建、抛出并捕获异常。如果过分的依赖异常处理,代码对易读和易使用这两方面产生影响,以至于会让我们写出上边两处“糟糕”代码。
异常原理
大体上说,有三种不同的“情景”会导致异常的抛出:
l 编程错误导致异常(Exception due Programming errors): 这种情景下,异常往往处于编程错误(如:NullPointerException 或者 IllegalArgumentException),这时异常一旦抛出,客户端将变得无能为力。
l 客户端代码错误导致异常(Exception due client code errors): 说白点就是客户端试图调用API不允许的操作。
l 资源失败导致异常(Exception due to resource failures): 如内存不足或网络连接失败导致出现异常等。这些异常的出现客户端可以采取相应的措施来恢复应用程序的继续运行。
Java中异常的类型
Java 中定义了两类异常:
l Checked exception: 这类异常都是Exception的子类
l Unchecked exception: 这类异常都是RuntimeException的子类,虽然RuntimeException同样也是Exception的子类,但是它们是特殊的,它们不能通过client code来试图解决,所以称为Unchecked exception
举个例子,下图为NullPointerException的继承关系:
ASPectratio="t">
Figure 1. Sample exception hierarchy
图中,NullPointerException继承自RuntimeException,所以它是Unchecked exception.
以往我都是应用checked exception多于Unchecked exception,最近,在java社区激起了一场关于checked exception和使用它们的价值的争论。这场争论起源于JAVA是第一个拥有Checked exception的主流OO语言这样一个事实,而C++和C#都是根本没有Checked exception,它们所有的异常都是unchecked。
一个checked exception强迫它的客户端可以抛出并捕获它,一旦客户端不能有效地处理这些被抛出的异常就会给程序的执行带来不期望的负担。
Checked exception还可能带来封装泄漏,看下面的代码:
public List getAllAccounts() throws
FileNotFoundException, SQLException{
...
}
上边的方法抛出两个异常。客户端必须显示的对这两种异常进行捕获和处理即使是在完全不知道这种异常到底是因为文件还是数据库操作引起的情况下。因此,此时的异常处理将导致一种方法和调用之间不合适的耦合。
接下来我会给出几种设计异常的最佳实践 (Best Practises for Designing the API)
1. 当要决定是采用checked exception还是Unchecked exception的时候,你要问自己一个问题,“如果这种异常一旦抛出,客户端会做怎样的补救?”
[原文:When deciding on checked exceptions vs. unchecked exceptions, ask yourself, "What action can the client code take when the exception occurs?"]
如果客户端可以通过其他的方法恢复异常,那么这种异常就是checked exception;如果客户端对出现的这种异常无能为力,那么这种异常就是Unchecked exception;从使用上讲,当异常出现的时候要做一些试图恢复它的动作而不要仅仅的打印它的信息,总来的来说,看下表:
Client's reaction when exception happens
Exception type
Client code cannot do anything
Make it an unchecked exception
Client code will take some useful recovery action based on information in exception
Make it a checked exception
此外,尽量使用unchecked exception来处理编程错误:因为unchecked exception不用使客户端代码显示的处理它们,它们自己会在出现的地方挂起程序并打印出异常信息。Java API中提供了丰富的unchecked excetpion,譬如:NullPointerException , IllegalArgumentException 和 IllegalStateException等,因此我一般使用这些标准的异常类而不愿亲自创建新的异常类,这样使我的代码易于理解并避免的过多的消耗内存。
2. 保护封装性(Preserve encapsulation)
不要让你要抛出的checked exception升级到较高的层次。例如,不要让SQLException延伸到业务层。业务层并不需要(不关心?)SQLException。你有两种方法来解决这种问题:
l 转变SQLException为另外一个checked exception,如果客户端并不需要恢复这种异常的话;
l 转变SQLException为一个unchecked exception,如果客户端对这种异常无能为力的话;
多数情况下,客户端代码都是对SQLException无能为力的,因此你要毫不犹豫的把它转变为一个unchecked exception,看看下边的代码:
public void dataAccessCode(){
try{
..some code that throws SQLException
}catch(SQLException ex){
ex.printStacktrace();
}
}
上边的catch块紧紧打印异常信息而没有任何的直接操作,这是情有可原的,因为对于SQLException你还奢望客户端做些什么呢?(但是显然这种就象什么事情都没发生一样的做法是不可取的)那么有没有另外一种更加可行的方法呢?
public void dataAccessCode(){
try{
..some code that throws SQLException
}catch(SQLException ex){
throw new RuntimeException(ex);
}
}
上边的做法是把SQLException转换为RuntimeException,一旦SQLException被抛出,那么程序将抛出RuntimeException,此时程序被挂起并返回客户端异常信息。
如果你有足够的信心恢复它当SQLException被抛出的时候,那么你也可以把它转换为一个有意义的checked exception, 但是我发现在大多时候抛出RuntimeException已经足够用了。
3. 不要创建没有意义的异常(Try not to create new custom exceptions if they do not have useful information for client code.)
看看下面的代码有什么问题?
public class DuplicateUsernameException
extends Exception {}
它除了有一个“意义明确”的名字以外没有任何有用的信息了。不要忘记Exception跟其他的Java类一样,客户端可以调用其中的方法来得到更多的信息。
我们可以为其添加一些必要的方法,如下:
public class DuplicateUsernameException
extends Exception {
public DuplicateUsernameException
(String username){....}
public String requestedUsername(){...}
public String[] availableNames(){...}
}
在新的代码中有两个有用的方法:reqeuestedUsername(),客户但可以通过它得到请求的名称;availableNames(),客户端可以通过它得到一组有用的usernames。这样客户端在得到其返回的信息来明确自己的操作失败的原因。但是如果你不想添加更多的信息,那么你可以抛出一个标准的Exception:
throw new Exception("Username already taken");
更甚的情况,如果你认为客户端并不想用过多的操作而仅仅想看到异常信息,你可以抛出一个unchecked exception:
throw new RuntimeException("Username already taken");
另外,你可以提供一个方法来验证该username是否被占用。
很有必要再重申一下,checked exception应该让客户端从中得到丰富的信息。要想让你的代码更加易读,请倾向于用unchecked excetpion来处理程序中的错误(Prefer unchecked exceptions for all programmatic errors)。
4. Document exceptions.
你可以通过Javadoc’s @throws 标签来说明(document)你的API中要抛出checked exception或者unchecked exception。然而,我更倾向于使用来单元测试来说明(document)异常。不管你采用哪中方式,你要让客户端代码知道你的API中所要抛出的异常。这里有一个用单元测试来测试IndexOutOfBoundsException的例子:
public void testIndexOutOfBoundsException() {
ArrayList blankList = new ArrayList();
try {
blankList.get(10);
fail("Should raise an IndexOutOfBoundsException");
} catch (IndexOutOfBoundsException success) {}
}
上边的代码在请求blankList.get(10)的时候会抛出IndexOutOfBoundsException,如果没有被抛出,将fail("Should raise an IndexOutOfBoundsException")显示说明该测试失败。通过书写测试异常的单元测试,你不但可以看到异常是怎样的工作的,而且你可以让你的代码变得越来越健壮。
下面作者将介绍界中使用异常的最佳实践(Best Practices for Using Exceptions)
1. 总是要做一些清理工作(Always clean up after yourself)
如果你使用一些资源例如数据库连接或者网络连接,请记住要做一些清理工作(如关闭数据库连接或者网络连接),如果你的API抛出Unchecked exception,那么你要用try-finally来做必要的清理工作:
public void dataAccessCode(){
Connection conn = null;
try{
conn = getConnection();
..some code that throws SQLException
}catch(SQLException ex){
ex.printStacktrace();
} finally{
DBUtil.closeConnection(conn);
}
}
class DBUtil{
public static void closeConnection
(Connection conn){
try{
conn.close();
} catch(SQLException ex){
logger.error("Cannot close connection");
throw new RuntimeException(ex);
}
}
}
DBUtil是一个工具类来关闭Connection.有必要的说的使用的finally的重要性是不管程序是否碰到异常,它都会被执行。在上边的例子中,finally中关闭连接,如果在关闭连接的时候出现错误就抛出RuntimeException.
2. 不要使用异常来控制流程(Never use exceptions for flow control)
下边代码中,MaximumCountReachedException被用于控制流程:
public void useExceptionsForFlowControl() {
try {
while (true) {
increaseCount();
}
} catch (MaximumCountReachedException ex) {
}
//Continue execution
}
public void increaseCount()
throws MaximumCountReachedException {
if (count >= 5000)
throw new MaximumCountReachedException();
}
上边的useExceptionsForFlowControl()用一个无限循环来增加count直到抛出异常,这种做法并没有说让代码不易读,但是它是程序执行效率降低。
记住,只在要会抛出异常的地方进行异常处理。
3. 不要忽略异常
当有异常被抛出的时候,如果你不想恢复它,那么你要毫不犹豫的将其转换为unchecked exception,而不是用一个空的catch块或者什么也不做来忽略它,以至于从表面来看象是什么也没有发生一样。
4. 不要捕获顶层的Exception
unchecked exception都是RuntimeException的子类,RuntimeException又继承Exception,因此,如果单纯的捕获Exception,那么你同样也捕获了RuntimeException,如下代码:
try{
..
}catch(Exception ex){
}
一旦你写出了上边的代码(注意catch块是空的),它将忽略所有的异常,包括unchecked exception.
5. Log exceptions just once
Logging the same exception stack trace more than once can confuse the programmer examining the stack trace about the original source of exception. So just log it once.
总结
这里给出了一些关于异常处理的一些最佳实践,我并不想开始另一轮的关于checked exception 和 unchecked exception的争论。你可以根据自己的实际情况定制自己异常处理,我坚信我们将有更好的办法来处理我们代码中的异常。
在此,我将感谢Bruce Eckel, Joshua Kerievsky, 和Somik Raha对于写这篇文章所给于我的支持。
参考资源:
分享到:
相关推荐
7. **自定义异常**:如果Java内置的异常类无法满足特定需求,可以创建自定义异常类来更好地表示和处理应用程序特有的错误条件。 8. **异常处理策略**:根据异常处理的原则,应尽量在本地处理异常,如果无法处理,则...
对于特定业务场景下的异常,可以创建自定义异常类,扩展自Laravel的基础异常类。这样做可以更清晰地表达业务逻辑,同时方便在`RestHandler`中针对性地处理这些异常。 5. **中间件与异常处理** 在Laravel中,还...
自定义公共函数应该具备良好的错误处理机制,当函数执行失败时,能够抛出异常或者记录错误信息。可以创建一个`log_error($message)`函数,使用`error_log()`将错误信息写入日志文件,便于后期排查问题。 7. **性能...
Java允许创建自定义异常类,继承自java.lang.Throwable或其子类,如Exception。当需要表示特定业务逻辑错误时,自定义异常就很有用。 总结起来,Java异常处理是通过try-catch-finally结构来实现的,它使得程序能够...
- 分享在项目开发过程中积累的最佳实践,如代码组织方式、数据库设计原则等。 - 讨论如何有效地利用框架特性来提高开发效率和代码质量。 3. **常见问题与解决方案** - 总结在使用自定义MVC框架时遇到的问题及其...
5. **无障碍性**:考虑到不同类型的用户,尤其是有特殊需求的用户,如视力障碍者,自定义按钮状态切换时应遵循无障碍设计原则。比如,为按钮添加合适的aria属性,使用语义明确的标签,确保屏幕阅读器能够正确解读...
- **异常体系混乱**:自定义异常过多可能导致异常体系混乱,不易于理解和管理。 **改进方案**: 1. **合理设计异常层次结构**:合理规划异常体系,减少自定义异常的数量。 2. **遵循最佳实践**:参考Java标准库中的...
- **错误处理**:对可能出现的异常,如文件不存在、权限问题等,进行适当的错误处理和提示。 通过以上步骤,我们可以构建一个功能齐全的自定义图片查看器控件。这样的控件在许多Windows应用中都有实用价值,比如...
- C++的异常处理机制采用的是不唤醒(no-failure)原则,即一旦出现异常,程序会立即停止当前执行路径,转而去寻找合适的异常处理器。 2. **异常类型**: - 异常分为编译错误和运行错误。编译错误通常是语法错误...
考虑到Android设备的多样性,源码可能包含了针对不同屏幕尺寸和分辨率的适配策略,以及符合Material Design原则的UI设计。此外,还需要处理横竖屏切换时的数据保存和恢复。 10. **错误处理与日志记录** 在开发...
Java提供了丰富的异常体系,包括标准的Java异常类和自定义异常。 1. **算术异常类:ArithmeticException** - 当程序执行了非法的数学运算,如除以零,就会抛出此异常。 2. **空指针异常类:NullPointerException**...
此外,自定义异常也是常见的做法,通过继承Exception类或其子类,可以创建具有特定含义的异常,使代码更具可读性和可维护性。在处理异常时,推荐采用“就近原则”,即尽量在异常发生的地方进行处理,减少异常传播的...
自定义异常类通常继承自`Exception`或其子类,并提供相应的构造函数和方法。下面是一个简单的自定义异常示例: ```java class MyException extends Exception { public MyException(String message) { super...
总结来说,Laravel的错误处理和错误代码管理是通过异常处理器、日志系统、`try...catch`块、自定义异常类以及中间件等工具来实现的。理解并熟练运用这些机制,可以极大地提高代码的健壮性和维护性,从而提升整个项目...
另外,开发者还可以通过throw关键字抛出自定义异常,以更精细地控制程序的执行流程。 为了更好地管理异常,开发者需要为不同的异常定义不同的处理方式,例如,一些异常可能需要记录日志之后重新抛出,而另一些异常...
2. 在数据解析层使用拦截器捕获错误,抛出自定义异常。 3. 使用 `onErrorResumeNext` 或其他错误处理策略,确保异常被捕获并在 `onError` 事件中处理。 4. 设计并实现 `ExceptionEngine`,负责将异常转换为用户友好...
Java异常处理是编程过程中的重要组成部分,它帮助开发者在程序执行期间...在编程实践中,应遵循异常处理的最佳实践,如使用try-catch-finally语句块,创建自定义异常类,以及尽可能恢复异常,而不是简单地忽略它们。
有时候,可能需要将一种类型的异常转换为另一种类型,例如,将`IOException`转换为自定义的业务异常。这可以通过在`catch`块中抛出新的异常来实现。 #### 4. 资源释放与`finally`块 无论是否发生异常,`finally`块...
2. **应用异常**:这类异常是开发者自定义的异常类型,通常用于处理那些会影响到用户交互的错误情况。当发生应用异常时,应当通过友好的消息告知用户,以确保用户体验不受影响。 - **示例**:用户尝试创建一个已...