Java异常处理高可读性的核心是清晰传达“谁、哪、为何、如何”，需语义化异常类型、分层定制、带上下文消息、脱敏敏感信息、catch块明确意图、善用try-with-resources和Optional。
Java异常处理的高可读性，核心在于让“谁出了问题、哪里出的问题、为什么出问题、该怎么应对”一目了然。不是堆砌try-catch，而是用结构和语义说话。
异常类型要语义清晰
避免泛用Exception或RuntimeException。自定义异常类名应直接反映业务意图，比如InsufficientBalanceException比BusinessException更明确；InvalidOrderStatusTransitionException比StateException更能说明上下文。
- 检查型异常（Checked）用于调用方**必须决策**的可恢复问题，如文件不存在、网络超时
- 非检查型异常（Unchecked）用于程序逻辑错误或不可恢复状态，如空指针、数组越界、非法参数
- 同一模块内异常继承体系不宜过深，2层以内为宜（如PaymentException → PaymentTimeoutException）
异常消息要带上下文，不裸抛
不要写throw new IllegalArgumentException("id is null")。ID是什么？哪个方法？哪个对象？补全关键变量值和执行路径。
- 推荐格式："Failed to process order [orderId=10023] with status [CANCELLED]: cannot apply discount"
- 敏感信息（如密码、token）必须脱敏，可用占位符代替："Invalid API key [***masked***] for tenant [T-789]"
- 日志中记录异常时，优先用log.error(msg, e)而非log.error(msg + e)，避免丢失堆栈
catch块要有明确意图，不静默吞异常
每个catch都该回答一个问题：“我为什么在这里捕获它？我要做什么？”没有处理动作的catch（尤其是空块）是可读性杀手。
立即学习“Java免费学习笔记（深入）”；
- 仅记录日志？写清楚为何只记日志：// Expected during graceful shutdown, ignore
- 转换异常？保留原始原因：throw new OrderProcessingException("Failed to persist audit log", e)
- 重试或降级？显式命名策略：handleTransientNetworkFailure(e) 或 fallbackToCachedInventory()
- 绝不写catch (Exception e) { }或catch (Throwable t) { System.exit(1); }
用try-with-resources和Optional减少异常干扰
把资源管理和空值判断从异常流程中剥离，让主干逻辑聚焦在“做什么”，而不是“防什么”。
- 文件/数据库连接等资源，统一用try-with-resources，避免finally里冗长的close逻辑和潜在NPE
- 对可能为空的返回值，用Optional表达契约，比抛NoSuchElementException更主动、更易读
- 工具方法如Objects.requireNonNull()或Preconditions.checkArgument()应在入参校验阶段快速失败，而不是拖到深层逻辑才爆异常
基本上就这些。可读的异常处理不是写得少，而是写得准——每行代码都在回答一个具体问题。不复杂，但容易忽略。
