7

我有一些关于在 Java 中处理异常的问题。我读了一些关于它的内容，并得到了一些相互矛盾的指导方针。

异常处理的最佳实践

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

它指出，如果“客户端代码无能为力” ，通常应该避免使用检查异常。但这究竟是什么意思？在 GUI 中显示错误消息是冒泡检查异常的充分理由吗？但它会迫使 GUI 程序员记住捕获 RuntimeExceptions 及其后代以显示潜在的错误信息。

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

我今天实现了一些代码，文章中介绍的“新方法”在这里和那里抛出 RuntimeException，然后我让Sonar分析它。为了让我更加困惑，Sonar 将我的 RuntimeExceptions 标记为重大错误，并带有一条消息，例如“避免抛出根类型异常，将它们包装在您自己的类型中”。

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

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

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

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

  2. '客户端对此无能为力，抛出运行时异常？'

  3. 性能问题呢？

4

1 回答 1

2

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

我的建议是：

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