关于在Java中处理异常，我有一些问题。我读了一些关于它的文章，得到了一些自相矛盾的指导方针。
异常处理的最佳实践
让我们浏览一下上面提到的文章：
它指出，如果"客户端代码无法执行任何操作"，通常应避免使用检查异常。但这到底意味着什么？在GUI中显示错误消息是否足以引发检查异常？但这会迫使GUI程序员记住捕捉RuntimeException及其后代以显示潜在的错误信息。
本文中提出的第二种观点是，除非我想在其中实现一些自定义字段/方法，否则应该避免发明自己的异常类。我通常不同意这一点，我今天的实践正好相反：我将异常封装在自己的异常结构中，以反映我编写的类实现的目标，即使它们只是扩展了exception而没有添加任何新方法。我认为这有助于在抛出时在更高层更灵活地处理它们，而且对于使用这些类的程序员来说，这通常更清晰易懂。
我今天实现了一些代码"新方法"，在文章中到处抛出RuntimeException，然后我让Sonar分析它。为了让我更困惑，Sonar用这样的消息将我的RuntimeException标记为重大错误："避免抛出根类型异常，用你自己的类型包装">
所以这看起来很有争议，你觉得呢？
我还从今天的一位技术负责人那里听说，仅仅包装异常是不好的，"因为这对JVM来说是一项非常昂贵的操作"。对我来说，另一方面，到处抛出SQLExceptions或IOExceptions看起来有点破坏封装。。
那么，你对我在这里提出的问题的总体态度是什么
-
什么时候用我自己的类型包装异常，什么时候不应该这样做
-
客户对此无能为力，抛出运行时异常'
-
性能问题怎么办
你的技术负责人似乎经常因为不擅长开发而逃避了开发人员的角色。
我的建议是：
- 更喜欢运行时异常而不是检查异常，尤其是当您不是API的唯一客户端时。使用检查的异常会强制每个客户端处理该异常，即使它对此无能为力。如果这确实是你想要做的(即强制调用方处理它)，那么检查的异常就是你想要的
- 如果发生异常时，客户端唯一能做的就是显示或多或少的通用错误消息，例如"哎呀，发生了不好的事情，请重试或返回欢迎页面"，那么一定要使用运行时异常。大多数表示框架都提供了一种使用通用错误处理程序的方法
- 一定要使用链接到抽象层的异常。从高级服务抛出SQLException是不够的。在适当的情况下使用现有的异常类型(如发出非法参数信号的IllegalArgumentException)。否则，将低级别异常包装为更高级别、适当的异常类型。代价高昂的是抛出一个例外。它是否包裹另一个并不重要。无论如何，这种情况只会在特殊情况下发生