异常是设计语言的一部分，揭示职责边界与协作关系。当方法抛出异常，实则声明前提条件由调用者满足，如FileInputStream抛出FileNotFoundException表明文件存在非其职责；频繁异常提示依赖外置，如DAO抛SQLException将事务管理交服务层；检查型异常成契约一部分，迫使调用者处理预期失败，如PaymentRejectedException体现领域语义；抛出异常而非吞咽，避免职责膨胀，如配置解析器抛ConfigurationException保持专注，促进高内聚低耦合。
异常抛出在Java中不只是错误处理机制，它还深刻影响对象的设计方式。当一个方法抛出异常时，其实是在向调用者传达某种“职责边界”的信号：这个操作可能失败，而失败的后果不应由当前对象独自承担。这种设计上的提示作用，有助于我们更清晰地划分对象之间的职责。
异常揭示了行为的前提条件
当某个方法要求特定前提才能正确执行时，比如文件必须存在、网络连接必须可用，若这些条件不满足，就会抛出异常。这说明该方法并不负责确保环境准备就绪，而是假设调用者已经完成了相关准备工作。
例如，FileInputStream 构造函数在文件不存在时抛出 FileNotFoundException，这就表明“确保文件存在”不是输入流对象的职责，而是调用者的责任。这样的设计让每个类聚焦于核心功能，而不是处理所有可能的前置校验。
异常推动职责分离与协作
如果一个对象频繁抛出异常，往往意味着它依赖外部状态或资源，而这些依赖项的管理应交由其他组件负责。比如数据访问对象（DAO）抛出 SQLException，说明它不处理数据库连接的建立或事务控制，这部分逻辑应由服务层或事务管理器来承担。
立即学习“Java免费学习笔记（深入）”；
- DAO只关注SQL执行和结果映射
- 服务层捕获异常并决定重试、回滚或向上报告
- 客户端根据业务场景选择提示用户还是记录日志
通过异常的传递路径，各层之间的协作关系和责任边界变得明确。
异常类型本身就是接口契约的一部分
声明检查型异常（checked exception）相当于在方法签名中明确定义“这个操作可能会因某些受控原因失败”，迫使调用者主动思考失败情况。这促使开发者在设计时就要考虑错误流程，而不是仅关注正常路径。
比如一个支付接口抛出 PaymentRejectedException 或 InsufficientBalanceException，这些自定义异常不仅传递错误信息，也体现了领域语义，帮助调用方理解哪些问题是可以预期并处理的，哪些属于系统故障。
异常促进高内聚低耦合的设计
一个对象如果试图吞掉所有异常或自行恢复，往往会引入额外的逻辑，比如重试机制、降级策略、默认值填充等，导致职责膨胀。相反，合理抛出异常可以让对象保持专注。
例如，解析配置文件的类发现格式错误时直接抛出 ConfigurationException，而不尝试猜测意图或使用默认值，这样它的行为是可预测的，修复或容错的决策留给更高层的配置管理器去做。
基本上就这些。异常不是代码出错的标志，而是设计语言的一部分。它提醒我们谁该做什么，谁该对什么负责。善用异常，能让对象之间的协作更清晰，系统结构更稳健。
