Java异常处理的良好实践

Question

我有一些关于在Java中处理异常的问题。我读了一下它并得到了一些矛盾的指导原则。

Best Practices for Exception Handling

我们来看看上面提到的文章：

它指出，如果“客户端代码无法执行任何操作”，通常应避免使用已检查的异常。但它究竟意味着什么？在GUI中显示错误消息是否有足够的理由冒泡检查异常？但它会迫使GUI程序员记住捕获RuntimeExceptions及其后代以显示潜在的错误信息。

本文中提出的第二个观点是，除非我想在其中实现一些关税字段/方法，否则应该避免发明自己的异常类。 我通常不同意这一点，我今天的练习恰恰相反：我将自己的异常结构中的异常包装到我编写的类实现的反射目标中，即使它们只是在不添加任何新方法的情况下扩展Exception。我认为在抛出更高层时更灵活地处理它们对于使用这些类的程序员而言通常更清晰易懂。

我今天实现了一些代码，在这里和那里抛出RuntimeException的文章中提出了“新方法”，然后我让Sonar分析它。为了让我更加困惑，Sonar将我的RuntimeExceptions标记为主要错误，其中包含“避免在您自己的类型中抛出root类型异常，wrap'em”等消息。

所以它看起来很有争议，你怎么看？

我今天也从一位技术主管那里听说，只是包装异常是不好的，因为这对JVM来说是一项非常昂贵的操作。对我来说，另一方面，在任何地方抛出SQLExceptions或IOExceptions看起来都有点破解封装......

那么您对我在此提出的问题的一般态度是什么？

1. 何时在我自己的类型中包装异常，何时不应该这样做？

2. '客户端的哪一点无法做到这一点，抛出 运行时异常？ '

3. 性能问题怎么办？

Answer 1

看起来你的技术主管往往逃脱了他的开发者角色，因为他不擅长。

我的建议是：

• 更喜欢运行时异常而不是已检查的异常，尤其是如果您不是API的唯一客户端。使用已检查的异常会强制每个客户端处理异常，即使它无法对其执行任何操作。如果这确实是你想要做的（即强制调用者处理它），那么你需要一个经过检查的异常。
• 如果发生异常时客户端可以做的唯一事情是显示或多或少的一般性错误消息，例如“oops，发生了一些不好的事情，请重试或返回欢迎页面”，然后肯定使用运行时异常。大多数表示框架都提供了使用通用错误处理程序的方法。
• 绝对使用链接到您的抽象层的异常。从高级服务中抛出SQLException是不够的。在适当的时候使用现有的异常类型（比如IllegalArgumentException来表示非法参数）。否则，将低级异常包装到更高级别的相应异常类型中。成本高昂的是抛出异常。它是否包裹另一个并不重要。而且它应该只是异常地发生。