异常处理是Java编程中不可或缺的部分,但也是最容易被忽视或实现不当的环节。
优秀的异常处理机制不仅能提高系统的健壮性,还能让问题排查变得简单高效。
本文总结了Java异常处理的9种最佳实践,这些实践来自项目开发的经验总结,希望能帮助你避开常见陷阱,构建更加健壮和可维护的Java应用。
一、设计合理的异常层次结构
良好的异常设计应遵循层次化和语义化原则,这样有利于异常的分类处理和统一管理。
不良实践
// 所有异常使用同一个类型,缺乏语义
public class BusinessException extends RuntimeException {
public BusinessException(String message) {
super(message);
}
}
// 调用代码
if (user == null) {
throw new BusinessException("User not found");
} else if (user.getBalance() < amount) {
throw new BusinessException("Insufficient balance");
}
最佳实践
// 基础异常类
public abstract class BaseException extends RuntimeException {
private final String errorCode;
protected BaseException(String errorCode, String message) {
super(message);
this.errorCode = errorCode;
}
public String getErrorCode() {
return errorCode;
}
}
// 业务异常
public class BusinessException extends BaseException {
public BusinessException(String errorCode, String message) {
super(errorCode, message);
}
}
// 用户相关异常
public class UserException extends BusinessException {
public static final String USER_NOT_FOUND = "USER-404";
public static final String INSUFFICIENT_BALANCE = "USER-402";
public UserException(String errorCode, String message) {
super(errorCode, message);
}
public static UserException userNotFound(String userId) {
return new UserException(USER_NOT_FOUND,
String.format("User not found with id: %s", userId));
}
public static UserException insufficientBalance(long required, long available) {
return new UserException(INSUFFICIENT_BALANCE,
String.format("Insufficient balance: required %d, available %d", required, available));
}
}
// 调用代码
if (user == null) {
throw UserException.userNotFound(userId);
} else if (user.getBalance() < amount) {
throw UserException.insufficientBalance(amount, user.getBalance());
}
实施要点:
- 创建一个基础异常类,包含错误码和错误信息
- 按业务领域或功能模块设计异常子类
- 使用静态工厂方法创建常见异常,增强代码可读性
- 为错误码定义常量,便于统一管理和文档化
这种设计能让异常信息更加标准化,有利于排查问题和系统监控。
二、选择合适的异常类型
Java的异常分为检查型(checked)和非检查型(unchecked),何时使用哪种类型是开发者常困惑的问题。
基本原则
- 使用非检查型异常(RuntimeException)的场景:
-
- 程序错误(如空指针、数组越界)
- 不可恢复的系统错误
- 业务逻辑验证失败
- 使用检查型异常的场景:
-
- 调用者必须明确处理的情况
- 可恢复的外部资源错误(如网络、文件操作)
- API契约的一部分,要求调用者必须处理特定情况
实战代码
// 非检查型异常:业务逻辑验证失败
public void transferMoney(Account from, Account to, BigDecimal amount) {
if (amount.compareTo(BigDecimal.ZERO) <= 0) {
throw new IllegalArgumentException("Transfer amount must be positive");
}
if (from.getBalance().compareTo(amount) < 0) {
throw new InsufficientFundsException(
String.format("Insufficient funds: %s available, %s required",
from.getBalance(), amount));
}
// 执行转账逻辑
}
// 检查型异常:外部资源操作,调用者必须处理
public void saveReport(Report report, Path destination) throws IOException {
// 文件操作可能抛出IOException,这是合理的检查型异常
try (BufferedWriter writer = Files.newBufferedWriter(destination)) {
writer.write(report.getContent());
}
}
实践建议:
- 在微服务架构中,API边界通常使用非检查型异常,简化跨服务调用
- 在核心库和底层框架中,重要的错误状态应使用检查型异常强制处理
- 不要仅仅为了传递错误信息而使用检查型异常
推荐优先使用非检查型异常,除非确实需要强制调用者处理。
三、提供详尽的异常信息
异常信息的质量直接影响问题诊断的效率。一个好的异常信息应包含:错误上下文、失败原因和可能的解决方案。
不良实践
// 异常信息过于简单,缺乏上下文
if (product == null) {
throw new ProductException("Product not found");
}
if (product.getQuantity() < orderQuantity) {
throw new ProductException("Insufficient stock");
}
最佳实践
// 包含完整上下文的异常信息
if (product == null) {
throw new ProductNotFoundException(
String.format("Product not found with ID: %s, category: %s",
productId, categoryId));
}
if (product.getQuantity() < orderQuantity) {
throw new InsufficientStockException(
String.format("Insufficient stock for product '%s' (ID: %s): requested %d, available %d",
product.getName(), product.getId(), orderQuantity, product.getQuantity()),
product.getId(), orderQuantity, product.getQuantity());
}
提升异常信息质量的技巧:
- 使用参数化消息而非硬编码字符串
- 包含相关的业务标识符(如ID、名称)
- 提供操作相关的数值(如请求数量、可用数量)
- 在适当情况下提供解决建议
- 保存造成异常的原始数据
在实际项目中,详尽的异常信息能大大节约解决问题所花费的时间。
四、正确处理异常链,保留完整堆栈
异常链是保留原始错误信息的关键机制。不恰当的异常处理可能导致重要信息丢失,增加调试难度。
错误示例
// 错误示例1:吞噬异常
try {
fileService.readFile(path);
} catch (IOException e) {
// 错误:异常信息完全丢失
throw new ServiceException("File processing failed");
}
// 错误示例2:记录但吞噬原始异常
try {
userService.authenticate(username, password);
} catch (AuthenticationException e) {
// 错误:日志中有信息,但调用链中异常信息丢失
logger.error("Authentication failed", e);
throw new SecurityException("Invalid credentials");
}
正确处理
// 正确示例1:传递原始异常作为cause
try {
fileService.readFile(path);
} catch (IOException e) {
// 正确:保留原始异常作为cause
throw new ServiceException("File processing failed: " + path, e);
}
// 正确示例2:包装并重新抛出,保留原始异常信息
try {
userService.authenticate(username, password);
} catch (AuthenticationException e) {
logger.warn("Authentication attempt failed for user: {}", username);
throw new SecurityException("Authentication failed for user: " + username, e);
}
// 正确示例3:补充信息后重新抛出原始异常
try {
return jdbcTemplate.query(sql, params);
} catch (DataAccessException e) {
// 为异常添加上下文信息,但保持原始异常类型
throw new QueryException(
String.format("Database query failed. SQL: %s, Parameters: %s",
sql, Arrays.toString(params)), e);
}
最佳实践要点:
- 始终将原始异常作为cause传递给新异常
- 在新异常消息中包含相关上下文信息
- 只在能增加明确业务语义时才包装异常
- 考虑使用自定义异常属性保存更多上下文
- 避免多层包装同一异常,导致堆栈冗余
五、避免异常处理中的常见反模式
不良的异常处理模式不仅会导致代码质量下降,还会引入难以察觉的bug。
常见反模式及其解决方案
1. 空catch块
// 反模式
try {
Files.delete(path);
} catch (IOException e) {
// 什么都不做,错误被忽略
}
// 最佳实践
try {
Files.delete(path);
} catch (IOException e) {
logger.warn("Failed to delete file: {}, reason: {}", path, e.getMessage(), e);
// 如果确实可以忽略,至少解释原因
// 只有在确实可以安全忽略时才这样处理
}
2. 捕获顶层异常
// 反模式:捕获太广泛的异常
try {
processOrder(order);
} catch (Exception e) {
// 处理所有异常,包括那些不应该捕获的异常
sendErrorEmail("Order processing failed");
}
// 最佳实践:只捕获能处理的具体异常
try {
processOrder(order);
} catch (InvalidOrderException e) {
notifyCustomer(order, "Your order is invalid: " + e.getMessage());
} catch (InventoryException e) {
suggestAlternatives(order);
} catch (PaymentException e) {
retryPayment(order);
} catch (RuntimeException e) {
// 捕获其他未预期的运行时异常
logger.error("Unexpected error processing order: {}", order.getId(), e);
throw e; // 重新抛出,让上层处理
}
3. 在finally块中抛出异常
// 反模式:finally块抛出异常会覆盖try/catch块中的异常
Connection conn = null;
try {
conn = dataSource.getConnection();
// 数据库操作
} catch (SQLException e) {
logger.error("Database error", e);
} finally {
if (conn != null) {
try {
conn.close();
} catch (SQLException e) {
// 这个异常会覆盖try块中的异常
throw new RuntimeException("Failed to close connection", e);
}
}
}
// 最佳实践:使用try-with-resources或在finally中记录但不抛出异常
try (Connection conn = dataSource.getConnection()) {
// 数据库操作
} catch (SQLException e) {
logger.error("Database error", e);
throw new DatabaseException("Database operation failed", e);
}
4. 日志记录与抛出的重复
// 反模式:异常记录后又抛出,导致重复日志
try {
processPayment(payment);
} catch (PaymentException e) {
logger.error("Payment failed", e);
throw e; // 导致上层可能再次记录同一异常
}
// 最佳实践:在异常链的一处记录
try {
processPayment(payment);
} catch (PaymentException e) {
// 如果要重新抛出,不要记录,让最终处理者记录
throw new OrderException("Order processing failed during payment", e);
}
// 或者记录后转换为不同类型
try {
processPayment(payment);
} catch (PaymentException e) {
logger.error("Payment processing error", e);
// 转换为不同类型,表示已处理并记录
throw new OrderFailedException(e.getMessage());
}
六、使用try-with-resources进行资源管理
资源泄漏是Java应用中常见的问题,在异常处理中尤为突出。使用try-with-resources可以有效解决这一问题。
传统资源管理
// 传统方式:容易出错且冗长
FileInputStream fis = null;
BufferedReader reader = null;
try {
fis = new FileInputStream(file);
reader = new BufferedReader(new InputStreamReader(fis));
String line;
while ((line = reader.readLine()) != null) {
// 处理每一行
}
} catch (IOException e) {
logger.error("Error reading file", e);
} finally {
// 繁琐的资源关闭逻辑
if (reader != null) {
try {
reader.close();
} catch (IOException e) {
logger.error("Error closing reader", e);
}
}
if (fis != null) {
try {
fis.close();
} catch (IOException e) {
logger.error("Error closing file input stream", e);
}
}
}
使用try-with-resources
// 现代方式:简洁可靠
try (BufferedReader reader = new BufferedReader(
new InputStreamReader(new FileInputStream(file)))) {
String line;
while ((line = reader.readLine()) != null) {
// 处理每一行
}
} catch (IOException e) {
logger.error("Error reading file", e);
// 不需要finally块,资源会自动关闭
}
扩展:处理多个资源
// 处理多个资源
try (Connection conn = dataSource.getConnection();
PreparedStatement stmt = conn.prepareStatement(SQL_QUERY);
ResultSet rs = stmt.executeQuery()) {
while (rs.next()) {
// 处理结果集
}
} catch (SQLException e) {
throw new DatabaseException("Query execution failed", e);
}
自定义AutoCloseable资源
// 自定义资源类,实现AutoCloseable接口
public class DatabaseTransaction implements AutoCloseable {
private final Connection connection;
private boolean committed = false;
public DatabaseTransaction(DataSource dataSource) throws SQLException {
this.connection = dataSource.getConnection();
this.connection.setAutoCommit(false);
}
public void execute(String sql) throws SQLException {
// 执行SQL
}
public void commit() throws SQLException {
connection.commit();
committed = true;
}
@Override
public void close() throws SQLException {
if (!committed) {
// 未提交的事务自动回滚
connection.rollback();
}
connection.close();
}
}
// 使用自定义AutoCloseable资源
try (DatabaseTransaction transaction = new DatabaseTransaction(dataSource)) {
transaction.execute("INSERT INTO orders VALUES (?, ?, ?)");
transaction.execute("UPDATE inventory SET quantity = quantity - ?");
transaction.commit();
} catch (SQLException e) {
// 如果发生异常,transaction会自动关闭且回滚事务
throw new OrderException("Failed to process order", e);
}
使用try-with-resources不仅使代码更简洁,还能防止资源泄漏。在一个处理大量文件的系统中,切换到try-with-resources后,文件句柄泄漏问题完全消除,系统稳定性大大提高。
七、实现优雅的全局异常处理
特别是在Web应用和微服务中,全局异常处理可以集中管理异常响应,保持一致的错误处理策略。
Spring Boot中的全局异常处理
@RestControllerAdvice
public class GlobalExceptionHandler {
private static final Logger logger = LoggerFactory.getLogger(GlobalExceptionHandler.class);
// 处理业务异常
@ExceptionHandler(BusinessException.class)
public ResponseEntity<ErrorResponse> handleBusinessException(BusinessException ex) {
logger.warn("Business exception: {}", ex.getMessage());
ErrorResponse error = new ErrorResponse(
ex.getErrorCode(),
ex.getMessage(),
HttpStatus.BAD_REQUEST.value()
);
return new ResponseEntity<>(error, HttpStatus.BAD_REQUEST);
}
// 处理资源不存在异常
@ExceptionHandler(ResourceNotFoundException.class)
public ResponseEntity<ErrorResponse> handleResourceNotFoundException(ResourceNotFoundException ex) {
logger.warn("Resource not found: {}", ex.getMessage());
ErrorResponse error = new ErrorResponse(
"RESOURCE_NOT_FOUND",
ex.getMessage(),
HttpStatus.NOT_FOUND.value()
);
return new ResponseEntity<>(error, HttpStatus.NOT_FOUND);
}
// 处理接口参数验证失败
@ExceptionHandler(MethodArgumentNotValidException.class)
public ResponseEntity<ErrorResponse> handleValidationException(MethodArgumentNotValidException ex) {
List<String> errors = ex.getBindingResult()
.getFieldErrors()
.stream()
.map(error -> error.getField() + ": " + error.getDefaultMessage())
.collect(Collectors.toList());
logger.warn("Validation failed: {}", errors);
ErrorResponse error = new ErrorResponse(
"VALIDATION_FAILED",
"Validation failed: " + String.join(", ", errors),
HttpStatus.BAD_REQUEST.value()
);
return new ResponseEntity<>(error, HttpStatus.BAD_REQUEST);
}
// 处理所有其他异常
@ExceptionHandler(Exception.class)
public ResponseEntity<ErrorResponse> handleGenericException(Exception ex) {
logger.error("Unhandled exception occurred", ex);
ErrorResponse error = new ErrorResponse(
"INTERNAL_SERVER_ERROR",
"An unexpected error occurred. Please contact support.",
HttpStatus.INTERNAL_SERVER_ERROR.value()
);
// 生产环境不应该返回详细错误给客户端,但可以返回跟踪ID
error.setTraceId(generateTraceId());
return new ResponseEntity<>(error, HttpStatus.INTERNAL_SERVER_ERROR);
}
private String generateTraceId() {
return UUID.randomUUID().toString();
}
}
// 统一的错误响应格式
@Data
public class ErrorResponse {
private final String errorCode;
private final String message;
private final int status;
private String traceId;
private long timestamp = System.currentTimeMillis();
// 构造函数、getter和setter
}
实现高质量异常处理器的关键点:
- 区分不同类型的异常,给予不同的HTTP状态码
- 为生产环境异常提供追踪ID,方便关联日志
- 屏蔽敏感的技术细节,返回对用户友好的错误信息
- 记录适当的异常日志,区分警告和错误级别
- 为验证错误提供详细的字段错误信息
八、异常与日志结合的最佳实践
日志和异常处理应协同工作,既不重复又不遗漏关键信息。
异常日志记录原则
- 选择合适的日志级别:
-
- ERROR:影响系统运行的严重问题
- WARN:潜在问题或业务异常
- INFO:正常但重要的业务事件
- DEBUG:用于排查问题的详细信息
- 在异常链的一处记录:避免同一异常在多处记录,造成日志重复
- 包含上下文信息:不仅记录异常本身,还要包含相关业务数据
// 不良实践:缺乏上下文
try {
processOrder(order);
} catch (Exception e) {
logger.error("Order processing failed", e);
}
// 良好实践:包含相关上下文信息
try {
processOrder(order);
} catch (Exception e) {
logger.error("Order processing failed. OrderID: {}, Customer: {}, Amount: {}",
order.getId(), order.getCustomerId(), order.getAmount(), e);
}
MDC(Mapped Diagnostic Context)提升日志上下文
// 使用MDC添加上下文信息
public void processOrderWithMDC(Order order) {
// 放入MDC上下文
MDC.put("orderId", order.getId());
MDC.put("customerId", order.getCustomerId());
try {
// 此处所有日志自动包含orderId和customerId
logger.info("Started processing order");
validateOrder(order);
processPayment(order);
updateInventory(order);
logger.info("Order processed successfully");
} catch (PaymentException e) {
// 异常日志自动包含MDC中的上下文信息
logger.error("Payment processing failed", e);
throw new OrderProcessingException("Payment failed for order", e);
} catch (InventoryException e) {
logger.error("Inventory update failed", e);
throw new OrderProcessingException("Inventory update failed", e);
} finally {
// 清理MDC
MDC.clear();
}
}
结构化异常日志
对于复杂系统,考虑使用结构化日志格式如JSON,便于日志分析系统处理:
// 使用标准化结构记录异常
private void logStructuredError(Exception e, Map<String, Object> context) {
Map<String, Object> errorInfo = new HashMap<>();
errorInfo.put("type", e.getClass().getName());
errorInfo.put("message", e.getMessage());
errorInfo.put("context", context);
errorInfo.put("timestamp", Instant.now().toString());
errorInfo.put("thread", Thread.currentThread().getName());
if (e instanceof BaseException) {
errorInfo.put("errorCode", ((BaseException) e).getErrorCode());
}
try {
String jsonLog = objectMapper.writeValueAsString(errorInfo);
logger.error(jsonLog, e);
} catch (JsonProcessingException jpe) {
// 转换JSON失败,退回到简单日志
logger.error("Error processing order. Context: {}", context, e);
}
}
// 使用方式
try {
processOrder(order);
} catch (Exception e) {
Map<String, Object> context = new HashMap<>();
context.put("orderId", order.getId());
context.put("amount", order.getAmount());
context.put("customerId", order.getCustomerId());
logStructuredError(e, context);
throw e;
}
这种结构化日志对于ELK(Elasticsearch, Logstash, Kibana)等日志分析系统特别有用,能实现更高效的日志搜索和分析。
九、异常处理的性能考量
异常处理会影响系统性能。在高性能场景下,需要注意异常使用对性能的影响。
避免使用异常控制业务流程
异常应该用于异常情况,而不是正常的业务流程控制。
// 不良实践:使用异常控制流程
public boolean isUsernameTaken(String username) {
try {
userRepository.findByUsername(username);
return true; // 找到用户,用户名已存在
} catch (UserNotFoundException e) {
return false; // 没找到用户,用户名可用
}
}
// 良好实践:使用返回值控制流程
public boolean isUsernameTaken(String username) {
return userRepository.existsByUsername(username);
}
频繁操作避免创建和抛出异常
异常创建成本高,包含调用栈捕获,在热点代码中尤其要注意。
// 性能低下的实现
public int divide(int a, int b) {
if (b == 0) {
throw new ArithmeticException("Division by zero");
}
return a / b;
}
// 高性能实现:在外部API边界进行校验
public Result<Integer> divide(int a, int b) {
if (b == 0) {
return Result.error("Division by zero");
}
return Result.success(a / b);
}
// 返回对象定义
public class Result<T> {
private final T data;
private final String error;
private final boolean success;
// 构造函数、getter和工厂方法
public static <T> Result<T> success(T data) {
return new Result<>(data, null, true);
}
public static <T> Result<T> error(String error) {
return new Result<>(null, error, false);
}
}
总结
异常处理不仅仅是错误处理,更是系统可靠性设计的重要组成部分。
好的异常处理能够让系统在面对意外情况时保持稳定,为用户提供更好的体验。