在实践中,异常处理不单单是知道语法这么简单。编写健壮的代码是更像是一门艺术,在本文中,将讨论Java异常处理最佳实践。这些Java最佳实践遵循标准的JDK库,和几个处理错误和异常的开源代码。这还是一个提供给java程序员编写健壮代码的便利手册。Java 编程中异常处理的最佳实践
这里是我收集的10个Java编程中进行异常处理的10最佳实践。在Java编程中对于检查异常有褒有贬,强制处理异常是一门语言的功能。在本文中,我们将尽量减少使用检查型异常,同时学会在Java编程中使用检查型VS非检查型异常。
1)为可恢复的错误使用检查型异常,为编程错误使用非检查型错误。
选择检查型还是非检查型异常,对于Java编程人员来说,总是让人感到困惑。检查型异常保证你对错误条件提供异常处理代码,这是一种从语言到强制你编写健壮的代码的一种方式,但同时会引入大量杂乱的代码并导致其不可读。当然,如果你有替代品和恢复策略的话,捕捉异常并做些什么看起来似乎也在理。在Java 编程中选择检查型异常还是运行时异常,更多信息参考checked vs unchecked exceptions。
2)在finally程序块中关闭或者释放资源
这在Java编程中,是一个广为人知的最佳实践,在处理网络和IO类的时候,相当于一个标准。在finally块中关闭资源, 在正常和异常执行的情况下,保证之前和稀缺资源的合理释放,这由y finally块保证。从Java7开始,该语言有了一项更有趣的功能:资源管理自动化或者ARM块能实现这一功能。尽管如此,我们仍然要记住在finally块中关闭资源,这是对于释放像FileDescriptors这类,应用在socket和文件编程的情况下的有限资源很重要的。
3)在堆栈跟踪中包含引起异常的原因
很多时候,当一个由另一个异常导致的异常被抛出的时候,Java库和开放源代码会将一种异常包装成另一种异常。日志记录和打印根异常就变得非常重要。 Java异常类提供了 getCause()方法来检索导致异常的原因,这些(原因)可以对异常的根层次的原因提供更多的信息。该Java实践对在进行调试或排除故障大有帮助。时刻记住,如果你将一个异常包装成另一种异常时,构造一个新异常要传递源异常。
4)始终提供关于异常的有意义的完整的信息
异常信息是最重要的地方,因为这是程序员首先看到的第一个地方,这里你能找到问题产生的根本原因。这里始终提供精确的真实的信息。例如,对比IllegalArgumentException 异常的两条异常信息:
消息 1: “Incorrect argument for method”
消息 2: “Illegal value for ${argument}: ${value}
第一条消息仅说明了参数是非法的或者不正确,但第二条消息包括了参数名和非法值,而这对于找到错误的原因是很重要的。在用Java编程中编写异常处理代码的时候,始终遵循该Java最佳实践。
5)避免过度使用检查型异常
检查型异常在强制执行方面有一定的优势,但同时它也破坏了代码,通过掩盖业务逻辑使代码可读性降低。只要你不过度使用检查型异常,你可以最大限度的减少这类情况,这样做的结果是你会得到更清洁的代码。你同样可以使用Java7的新功能,像one catch block for multiple exceptions 和 automatic resource management以移除重复项。
6)将检查型异常转为运行时异常
这是在像Spring之类的多数框架中用来限制使用检查型异常的技术之一,大部分出自于JDBC的检查型异常,都被包装进 DataAccessException中,而(DataAccessException)异常是一种非检查型异常。这是Java最佳实践带来的好处,特定的异常限制到特定的模块,像 SQLException 放到DAO层,将意思明确的运行时异常抛到客户层。
7)记住对性能而言,异常代价高昂
需要记住的一件事是异常代价高昂,同时让你的代码运行缓慢。假如你有方法从ResultSet(结果集)中进行读取,这时常会抛出SQLException 异常而不会移到下一元素,这将会比不抛出异常的正常代码执行的慢的多。因此最大限度的减少不必要的异常捕捉和移动,那里没有什么固定的原因。不要仅仅是抛出和捕捉异常,如果你能使用boolean变量去表示执行结果,可能会得到更整洁,更高性能的解决方案。修正错误的根源,避免不必须要的异常捕捉。
8)避免catch块为空
没有什么比空的catch块更糟糕的了,因为它不仅隐藏了错误和异常,同时可能导致你的对象处于不可使用或者脏的状态。空的catch块只能变得无意义,如果你非常肯定异常不会继续以任何方式影响对象状态,但在程序执行期间,用日志记录错误依然是最好的(方法)。对于在Java编程中编写异常处理代码,这不仅仅是一个Java最佳实践,而是一个最通用的实践。
9)使用标准异常
我们的第九条最佳实践建议使用标准和内置的Java异常。使用标准异常而不是每次创建我们自己的异常,对于维护性和一致性,不管是现在还是以后,都是最好的选择。重用标准异常使代码更具可读性,因为大部分Java开发人员对标准的像源自于JDK的RuntimeException 异常,IllegalStateException 异常,IllegalArgumentException 异常或者NullPointerException异常,(开发者)他们能一眼就知道每种异常的目的,而不是在代码里查找或者在文档里查找用户定义的异常的目的。
10)记录任何方法抛出的异常
Java提供了throw和throws关键字来抛出异常,在javadoc中用@throw记录任何方法可能会抛出的异常。如果你编写API或者公共接口,这就变得非常重要。任何方法抛出的异常都有相应的文档记录,这样你就能下意识的提醒任何使用(该方法)的人。 这些就是所有在Java编程中在处理异常的时候需要遵循的最佳实践。让我们知道了什么是在Java编程中编写异常处理代码时需要遵循的实践。
问题内容: 如果我的应用程序崩溃了,它会挂起几秒钟,然后Android告诉我该应用程序崩溃了,需要关闭。所以我当时想用通用的方式捕获应用程序中的所有异常: 并做一个新的解释,说明应用程序立即崩溃(并且还使用户有机会发送包含错误详细信息的邮件),而不是由于Android而造成了延迟。是否有更好的方法来实现这一目标? 更新: 我使用的是启用了ART的Nexus 5,但我没有注意到我以前遇到的崩溃(我最
问题内容: 几天前我才开始尝试使用node.js。我意识到只要程序中有未处理的异常,Node就会终止。这与我所见过的普通服务器容器不同,在普通服务器容器中,当发生未处理的异常时,只有工作线程死亡,并且容器仍然能够接收请求。这引起了一些问题: 是唯一有效的预防方法吗? 在执行异步过程期间也会捕获未处理的异常吗? 是否存在已经构建的模块(例如发送电子邮件或写入文件),在未捕获的异常的情况下可以利用该模
并创建一个新的,解释应用程序立即崩溃(并给用户发送包含错误详细信息的邮件的机会),而不是由于Android造成的延迟。有没有更好的方法来实现这一点,或者这是不鼓励的? 更新:我使用的Nexus 5启用了ART功能,我没有注意到应用程序崩溃时的延迟(我最初说的“挂起”)。我想既然现在一切都是本机代码,崩溃就会立即发生,同时得到所有的崩溃信息。也许Nexus5只是速度很快:)不管怎样,这在未来的And
本文向大家介绍浅析Lua编程中的异常处理,包括了浅析Lua编程中的异常处理的使用技巧和注意事项,需要的朋友参考一下 需要进行错误处理 错误处理是必要的,因为真实世界中的操作通常需要使用复杂的操作,包括文件操作,数据库事务和web服务调用。没人关心错误的业务,涉及保密信息或金钱交易时造成大的损失。 在任何编程,总是有错误处理的要求。错误可以是两种类型,其中包括, 语法错误 运行时错
本文向大家介绍Java 中的异常处理?相关面试题,主要包含被问及Java 中的异常处理?时的应答技巧和注意事项,需要的朋友参考一下 Java异常类层次结构图 在 Java 中,所有的异常都有一个共同的祖先java.lang包中的 Throwable类。Throwable: 有两个重要的子类:Exception(异常) 和 Error(错误) ,二者都是 Java 异常处理的重要子类,各自都包含大
问题内容: 我更喜欢将异常处理逻辑放在main方法附近的调用堆栈中。我喜欢这种方法…但是,我创建了一个线程,该线程的run()内部的某些方法调用可能会引发异常。我真的很想看看是否有一种方法可以将这些异常返回到父线程?我能想到的最好的办法是在实现的对象内部设置一个变量。该变量是一个包含错误消息的字符串,该错误消息随后使用类加载器在父线程中正确地重新创建相同的异常。 我想知道的是,在这里得到想要的东西