Javaexception处理的良好实践

我有一些关于在Java中处理exception的问题。 我读了一下它并得到了一些矛盾的指导方针。

exception处理的最佳实践

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

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

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

我今天实现了一些代码，这篇文章在抛出RuntimeException的文章中提出了“新方法”，然后让Sonar分析它。 为了让我更加困惑，Sonar将我的RuntimeExceptions标记为主要错误，并标记为“避免在自己的类型中抛出root类型exception，wrap’em”。

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

我还从今天的技术主管之一那里得知，只是包装exception是不好的，因为这对JVM来说是一个非常昂贵的操作。 对我来说，另一方面，在任何地方抛出SQLExceptions或IOExceptions看起来像是一些打破封装。

那么你对我在这里提出的问题的一般态度是什么？

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

2. 那个‘客户端无法做到这一点的地方，抛出运行时exception？ “

3. 性能问题怎么样？

Answer 1

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

我的建议是：

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