Java异常处理的良好实践

Question

我对处理Java中的异常有一些疑问。我读了一些，并得到了一些相互矛盾的指导方针。

异常处理的最佳实践

让我们看一下提到的文章：

它指出， 如果“客户端代码无法执行任何操作”，
通常应该避免使用检查的异常。但这到底是什么意思？在GUI中显示错误消息是否是冒充受检查的异常的充分原因？但这将迫使GUI程序员记住记住RuntimeException及其后代以显示潜在的错误信息。

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

今天，我实现了这篇文章中介绍的代码“新方法”中的一些“新方法”，然后在这里到处抛出RuntimeException，然后让Sonar对其进行分析。为了使我更加困惑，Sonar将诸如
“避免引发根类型异常，以自己的类型包装”之类 的消息标记我的RuntimeExceptions为重大错误 。

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

我还从今天的一位技术负责人那里听说，仅包装异常是不好的，因为“这对于JVM来说确实是一项昂贵的操作”。对我来说，另一方面，到处都抛出SQLExceptions或IOExceptions似乎有点破坏封装。

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

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

2. “客户端对此无能为力，抛出运行时异常”的 观点在哪里 ？ ‘

3. 那么性能问题呢？

Answer 1

看起来您的技术主管经常因为他不擅长而逃离了开发人员的角色。

我的建议是：

• 与运行时异常相比，更喜欢运行时异常，特别是如果您不是API的唯一客户端时。使用已检查的异常会强制每个客户端处理该异常，即使它无法对此做任何事情。如果这确实是您想要执行的操作（即，强制调用者处理它），那么您想要的就是一个检查异常。
• 如果客户端在发生异常时唯一能做的就是显示或多或少的通用错误消息，例如“哎呀，发生了不好的事情，请重试或返回到欢迎页面”，那么绝对可以使用运行时异常。大多数表示框架都提供了使用通用错误处理程序的方法。
• 绝对使用链接到抽象层的异常。从高级服务中抛出SQLException是不够的。在适当时使用现有的异常类型（例如IllegalArgumentException表示非法参数）。否则，请将低级异常包装为较高级别的适当异常类型。代价高昂的是抛出异常。是否包装另一个都无关紧要。而且它无论如何都应该例外地发生。