if(amount < 0) {
throw new IllegalArgumentException("转账金额不能为负数");
}
throw new ExceptionType("异常描述信息");
// throw的使用 public void validateAge(int age) {
if(age < 0) {
throw new IllegalArgumentException("年龄不能为负数");
}
}
// throws的使用 public void processFile(String filename) throws IOException {
// 可能抛出IOException的代码
}
4.1 何时应该使用throw抛出异常
异常抛出不是越多越好，也不是越少越好。关键在于找到那个平衡点。一般来说，throw应该在真正“异常”的情况下使用——那些破坏了方法契约、无法继续正常执行的场景。
参数验证是个典型的例子。当传入的参数不满足方法的前提条件时，立即抛出异常比继续执行产生错误结果要好得多。比如一个计算年龄的方法收到负数，或者一个文件处理方法收到空路径，这些都是使用throw的合适时机。
业务规则违反也是throw的用武之地。我记得在一个电商项目中，有用户试图购买库存为零的商品，我们就在库存检查处抛出了InsufficientStockException。这种异常清晰地表达了业务逻辑的约束被打破。
状态检查同样重要。对象在特定状态下才能执行某些操作，如果状态不满足就抛出IllegalStateException。想象一下试图从空栈中弹出元素，或者对已关闭的连接执行操作，这些都应该立即抛出异常。
但并非所有错误情况都需要throw。有些情况下，返回特殊值或使用Optional可能是更好的选择。比如查找用户时没找到，返回Optional.empty()比抛出异常更合适，因为“用户不存在”在这种场景下可能不算真正的异常情况。
4.2 throw使用的常见错误和陷阱
新手在使用throw时容易掉进几个坑。最常见的就是在finally块中抛出异常，这会掩盖try块中抛出的原始异常，导致调试困难。
过度使用throw也是个问题。有些开发者喜欢在任何小问题上都抛出异常，结果代码变成了异常处理的迷宫。异常应该留给真正需要中断正常流程的情况，而不是用来处理预期的业务分支。
另一个陷阱是抛出的异常信息不够明确。像throw new Exception("错误发生")这样的代码，除了告诉你有错误外，几乎没有任何帮助。好的异常信息应该包含足够的上文信息，让人一眼就能看出问题所在。
异常链的丢失也是个常见错误。当你捕获一个异常然后抛出另一个时，记得把原始异常作为cause传递进去。否则，调试时就像在黑暗中摸索，看不到问题的根源。
空指针异常的处理也需要小心。有些开发者习惯在任何可能为空的地方都加上null检查并抛出异常，这可能导致代码变得冗长。更好的做法是使用Objects.requireNonNull()或者在设计上避免null值的出现。
4.3 异常类型选择的最佳实践
选择合适的异常类型是一门艺术。Java提供了丰富的异常类层次，理解它们的语义很重要。
运行时异常（RuntimeException及其子类）通常表示编程错误：空指针、数组越界、非法参数等。这些异常不需要在方法签名中声明，调用者也不强制处理。
受检异常（Checked Exception）则表示外部因素导致的错误：文件不存在、网络中断、数据库连接失败等。这些必须在方法签名中声明，调用者必须处理。
自定义异常应该在现有异常类无法准确表达业务语义时使用。比如在银行系统中，InsufficientBalanceException比通用的IllegalArgumentException更能清晰地表达业务约束。
异常粒度的把握也很关键。太粗的异常类型（总是抛出Exception）失去了类型安全的好处；太细的异常类型又会让调用者处理起来很麻烦。一个实用的建议是：为每个不同的处理策略定义一个异常类型。
性能考虑也不能忽视。创建异常对象是有成本的，因为要收集栈轨迹信息。在性能敏感的代码路径中，应该避免频繁抛出异常。有时候，使用错误码或特殊返回值可能是更好的选择。
异常的选择还应该考虑调用者的便利。如果调用者很可能需要根据异常类型采取不同行动，就提供足够细分的异常类型；如果所有异常的处理方式都相同，一个通用的异常类型可能就足够了。
掌握这些最佳实践，你的异常处理代码会变得更加优雅和实用。好的异常处理不是事后补救，而是从一开始就融入设计的思考方式。
5.1 自定义异常与throw的结合使用
自定义异常让异常处理变得更加语义化。当Java标准库中的异常类型无法准确描述你的业务场景时，就该考虑创建自己的异常类了。
我参与过一个物流系统项目，其中包裹状态流转有严格的规则。当系统检测到非法状态转换时，我们创建了InvalidPackageStateException。这个自定义异常不仅包含了错误信息，还封装了当前状态和目标状态，调试时一目了然。
创建自定义异常通常需要继承RuntimeException或Exception。选择父类时有个简单原则：如果异常表示的是编程错误或不可恢复的错误，继承RuntimeException；如果是外部因素导致的、可能恢复的错误，继承Exception。
自定义异常可以添加额外的字段来携带上下文信息。比如一个支付异常可以包含交易金额、支付方式、失败原因码等。这些信息在问题排查时非常有用，比单纯的错误消息更有价值。
异常命名的艺术也值得注意。好的异常名称应该清晰表达问题本质，遵循“XXXException”的命名模式。ValidationException就比GenericException好得多，前者直接告诉开发者这是验证相关的问题。
5.2 在方法链中正确使用throw
方法调用链中的异常处理需要格外小心。异常应该在哪一层抛出，在哪一层处理，这是个设计问题。
深层的异常不应该直接暴露给上层调用者。想象一个三层架构：Controller调用Service，Service调用DAO。如果DAO抛出的SQLException直接传到Controller，就破坏了分层隔离的原则。更好的做法是在Service层捕获底层异常，转换为业务相关的异常再抛出。
异常包装是个常用技巧。当底层技术异常需要转换为业务异常时，记得保留原始异常作为cause。这样既保持了抽象的清晰，又不丢失调试信息。
有时候，在方法链的中间层处理异常是合适的。比如一个批量处理操作，某个子项失败不应该中断整个流程。这时可以记录异常，继续处理其他项，最后汇总报告所有失败情况。
方法签名中的异常声明也需要谨慎设计。声明太多受检异常会让调用者负担过重；声明太少又可能隐藏重要的错误信息。一个经验法则是：只声明那些调用者确实需要知道、能够处理的异常。
5.3 性能优化与异常处理的最佳平衡
异常处理不是免费的午餐。创建异常对象时，JVM需要收集栈轨迹信息，这个操作相对昂贵。
在性能关键路径上，要避免使用异常来控制正常流程。比如在解析器中使用异常来处理每个语法错误，或者在循环中频繁抛出异常，都会对性能产生明显影响。
我记得优化过一个XML解析器，原来的实现遇到未知标签就抛出异常。当处理大型文件时，性能差得让人无法接受。后来改为使用错误收集器模式，性能提升了数十倍。
但也不要过度担心异常的性能影响。在真正的异常情况下——那些很少发生但一旦发生就需要立即处理的场景——抛出异常的性能成本是可以接受的。关键是要区分"异常"和"预期中的错误情况"。
异常预创建是个优化技巧。对于需要频繁抛出的相同异常，可以考虑预先创建异常实例（不包含栈信息），然后在抛出时填充栈信息。不过这种优化要谨慎使用，因为会丢失一些调试信息。
现代JVM的异常处理性能已经相当不错。在大多数业务场景中，代码的可读性和可维护性比微小的性能优化更重要。只有在性能分析明确指向异常处理是瓶颈时，才需要考虑优化。
找到性能与代码质量的平衡点，这需要经验和判断。好的开发者知道什么时候该为性能优化异常处理，什么时候该优先考虑代码的清晰度。