Java异常处理的良好做法 [英] Good practices for Java exceptions handling

问题描述

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

异常处理的最佳做法

我们来浏览所提到的文章：

它指出，如果客户端代码无法执行任何操作，应该通常避免使用被检查的异常。但它是什么意思？在GUI中显示错误消息有足够的原因冒泡检查异常吗？但是它会强制GUI程序员记住捕获RuntimeExceptions及其后代以显示潜在的错误信息。

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

我今天实现了一些代码文章中提到的新方法在这里和那里抛出RuntimeException，然后我让声纳分析它。为了混淆我更多的声呐标记我的RuntimeExceptions作为主要错误与消息像避免抛出根类型异常，wrap'em在你自己的类型。

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

我今天也听说过一个技术人员，只是包装例外是坏的，因为它是一个非常昂贵的JVM操作。对于我来说，另一方则是抛出SQLExceptions或IOExceptions，似乎有点破解封装。

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

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




2. 客户端的这一点在哪里不能做任何事情，抛出
   运行时异常？ / strong>'




3. 性能问题如何？

解决方案

看起来像你的技术领先者一样，已经逃脱了他的开发者的角色，因为他不擅长。

我的建议是：

• 如果您不是API的唯一客户端。使用被检查的异常强制每个客户端处理异常，即使它不能做任何事情。如果这真的是你想要做的（即强制调用者来处理它），那么一个被检查的异常就是你想要的。


• 如果客户端只能在一个异常正在显示一个或多或少的通用错误消息，如哎呀，发生了什么事情，请重试或回到欢迎页面，然后肯定使用运行时异常。大多数演示框架提供了一种使用通用错误处理程序的方法。


• 绝对使用链接到您的抽象层的异常。从高级别服务中抛出SQLException是不够的。使用现有的异常类型（如IllegalArgumentException表示非法参数）。否则，将低级异常包装到更高级别的适当的异常类型中。什么是昂贵的是抛出异常。无论是否包裹另一个都不重要。而且应该只会发生异常。

I have some questions regarding handling exceptions in Java. I read a bit about it and got some contradicting guidelines.

Best Practices for Exception Handling

Let's go through the mentioned article:

It states that one should generally avoid using checked exceptions if "Client code cannot do anything". But what does it exactly mean? Is displaying error message in GUI sufficient reason for bubbling up checked exception? But it would force GUI programmer to remember to catch RuntimeExceptions and their descendants to display potential error info.

Second view presented in this article is that one should evade inventing own exception classes unless I want to implement some customs field/methods in them. I generally disagree with this, my practice up today was just the opposite: I wrapped exceptions in my own exception structure to reflex goals realized by classes I write, even if they just extend Exception without adding any new methods. I think it helps to handle them more flexibly in the higher layers when thrown plus it's generally more clear and comprehensible for programmer who will use these classes.

I implemented some code today 'new way' presented in the article throwing RuntimeException here and there, then I let Sonar analyze it. To confuse me even more Sonar marked my RuntimeExceptions as Major errors with a message like "Avoid throwing root type exceptions, wrap'em in your own types".

So it looks quite controversional, what do you think?

I also heard from one of tech-leads today that just wrapping exceptions is bad, 'because it's a really costly operation for JVM'. For me, on the other side throwing SQLExceptions or IOExceptions everywhere looks like a bit of breaking encapsulation..

So what is your general attitude to questions I presented here?

1. When to wrap exceptions in my own types, when I shouldn't do this?

2. Where is that point of 'client cannot do anything about this, throw runtime exception?'

3. What about performance issues?

解决方案

It looks like your tech-lead, as often, has escaped his role of developer because he wasn't good at it.

My advices would be:

• prefer runtime exceptions over checked exceptions, especially if you're not the only client of your API. Using a checked exception forces every client to handle the exception, even if it can't do anything about it. If this is really what you want to do (i.e. forcing the caller to handle it), then a checked exception is what you want.
• if the only thing the client can do when an exception happens is displaying a more or less generic error message such as "oops, something bad happened, please retry or go back to the welcome page", then definitely use runtime exceptions. Most of the presentation frameworks provide a way to use a generic error handler.
• definitely use exceptions that are linked to your abstraction layer. Throwing a SQLException from a high-level service is not adequate. Use existing exception types when they're appropriate (like IllegalArgumentException to signal an illegal argument). Otherwise, wrap the low-level exception into a higher-level, appropriate exception type. What is costly is to throw an exception. Whether it wraps another one or not doesn't matter much. And it should only happen exceptionally anyway.

这篇关于Java异常处理的良好做法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！