Java异常处理的良好实践

Question

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

异常处理的最佳实践

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

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

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

我今天实现了一些代码,在文章中抛出RuntimeException,然后我让Sonar分析它.为了让我更加困惑,Sonar将我的RuntimeExceptions标记为主要错误,并标记为"避免在自己的类型中抛出root类型异常,wrap'em".

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

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

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

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

2. 哪里的那点客户端"不能做任何有关这一点,抛出运行时异常？"

3. 性能问题怎么样？

Answer 1

看起来您的技术主管通常已经摆脱了开发人员的角色，因为他不擅长这一点。

我的建议是：

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