准则一 仅在确有异常条件下使用异常
顾名思义,异常只适用于确有异常的情况;它们不应该用于一般的控制流程。
// Do not use this hideous code for iteration over a collection!
try {
Iterator<Foo> i = collection.iterator();
while(true) {
Foo foo = i.next();
}
}
catch (NoSuchElementException e) {
}
比如上面这个代码,我们可以使用hasNext() 来控制循环流程而不是使用异常。基于异常的循环不仅混淆了代码的目的,降低了代码的性能,而且不能保证它能正常工作。
准则二 对可恢复情况使用 checked 异常,对编程错误使用运行时异常
使用 checked 异常的情况是为了合理地期望调用者能够从中恢复。 通过抛出一个 checked 的异常,你可以强制调用者在 catch 子句中处理异常,或者将其传播出去。因此,方法中声明的要抛出的每个 checked 异常,都清楚的向 API 用户表明:the associated condition is a possible outcome of invoking the method.
受检异常 (Checked Exceptions)
定义:受检异常是在编译时必须处理的异常。如果一个方法声明抛出受检异常,则调用该方法的代码必须要么捕获这个异常,要么在其方法签名中声明抛出此异常。
用途:通常用于处理可预见的、应用程序可以恢复的情况,如文件不存在、网络连接中断等。
示例:IOException, SQLException 等。
运行时异常 (Runtime Exceptions)
定义:运行时异常是在运行时发生的异常,编译器不会强制要求处理这些异常。它们通常是由编程错误引起的,如数组越界、空指针引用等。
用途:通常用于指示程序逻辑错误或违反 API 规则的情况。
示例:NullPointerException, ArrayIndexOutOfBoundsException, IllegalArgumentException 等。
原则
- 对可恢复的情况使用受检异常:当遇到可预见的、应用程序可以采取措施恢复的异常时,应该使用受检异常。这样可以确保调用者意识到这些异常的可能性,并采取适当的措施来处理它们。
例如,如果一个方法需要读取文件,但文件不存在,它应该抛出 FileNotFoundException,这是一个受检异常,这样调用者就必须处理这种情况。 - 对编程错误使用运行时异常:当遇到编程错误时,应该使用运行时异常。这些错误通常是不应该发生的,因为它们通常表明代码中有逻辑错误或者违反了 API 的使用规则。
例如,如果一个方法期望一个非空的参数列表,而传入了一个空列表,它应该抛出 IllegalArgumentException,这是一个运行时异常,表明这是调用者的错误。
准则三 避免不必要地使用 checked 异常
checked 异常可以提高程序的可靠性;当过度使用时,它们会使 API 难以使用。如果调用者不应从失败中恢复,则抛出 unchecked 异常。如果恢复是可能的,并且你希望强制调用者处理异常条件,那么首先考虑返回一个 Optional 对象。只有当在失败的情况下,提供的信息不充分时,你才应该抛出一个 checked 异常。
准则四 鼓励复用标准异常
没啥好说的,意思就是可以使用定义好的标准异常,当然我们也可以自定义标准异常。
准则五 抛出能用抽象解释的异常
高层应该捕获低层异常,并确保抛出的异常可以用高层抽象解释。
一比如可以直接将异常转换为语义更明确的异常:
public E get(int index) {
ListIterator<E> i = listIterator(index);
try {
return i.next();
}
catch (NoSuchElementException e) {
throw new IndexOutOfBoundsException("Index: " + index);
}
}
或者我们将低层的异常传递给作为原因传递给高层,异常会接受一个ThrowAble 参数,进行传递。
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;
public class UserService {
private Connection getConnection() throws SQLException {
return DriverManager.getConnection("jdbc:mysql://localhost:3306/mydb", "user", "password");
}
public void createUser(String username, String password) throws UserCreationException {
try (Connection connection = getConnection()) {
// 执行数据库操作
// 假设这里抛出了 SQLException
throw new SQLException("Database error");
} catch (SQLException e) {
// 转译 SQLException 为 UserCreationException
throw new UserCreationException("Failed to create user", e);
}
}
}
class UserCreationException extends Exception {
public UserCreationException(String message, Throwable cause) {
super(message, cause);
}
}
准则六 异常详细消息中应包含捕获失败的信息
这个和上面的准则有点重复,也就是说我们需要将cause进行传递。
准则七 尽力保证故障原子性
在对象抛出异常之后,通常希望对象仍然处于定义良好的可用状态,即使在执行操作时发生了故障。对于 checked 异常尤其如此,调用者希望从异常中恢复。一般来说,失败的方法调用应该使对象处于调用之前的状态。 具有此属性的方法称为具备故障原子性。
准则八 不要忽略异常
如果你选择忽略异常,catch 块应该包含一条注释,解释为什么这样做是合适的。