了解 Java 中的检查异常与非检查异常

发布于 2024-11-09 19:05:50 字数 1784 浏览 0 评论 0原文

Joshua Bloch 在《Effective Java》中说道

使用检查异常可恢复条件和运行时间编程错误的例外情况（第二版第58条）

让我们看看我是否理解正确。

以下是我对检查异常的理解：

try{
    String userInput = //read in user input
    Long id = Long.parseLong(userInput);
}catch(NumberFormatException e){
    id = 0; //recover the situation by setting the id to 0
}

1.上述是否被认为是受检查的异常？

2. RuntimeException是未经检查的异常吗？

以下是我对未经检查的异常的理解：

try{
    File file = new File("my/file/path");
    FileInputStream fis = new FileInputStream(file);   
}catch(FileNotFoundException e){

//3. What should I do here?
    //Should I "throw new FileNotFoundException("File not found");"?
    //Should I log?
    //Or should I System.exit(0);?
}

4。现在，上面的代码难道不能也是一个受检查的异常吗？我可以尝试这样挽回局面吗？我可以吗？（注意：我的第三个问题在上面的catch中）

try{
    String filePath = //read in from user input file path
    File file = new File(filePath);
    FileInputStream fis = new FileInputStream(file);   
}catch(FileNotFoundException e){
    //Kindly prompt the user an error message
    //Somehow ask the user to re-enter the file path.
}

5。人们为什么要这样做？

public void someMethod throws Exception{

}

为什么他们会让异常冒出来？越早处理错误不是更好吗？为什么会冒泡？

6.我应该冒出确切的异常还是使用 Exception 屏蔽它？

下面是我的阅读内容

在 Java 中，什么时候应该创建检查异常，什么时候应该是运行时异常？

何时选择检查和非检查异常

原文

Joshua Bloch in "Effective Java" said that

Use checked exceptions for
recoverable conditions and runtime
exceptions for programming errors
(Item 58 in 2nd edition)

Let's see if I understand this correctly.

Here is my understanding of a checked exception:

try{
    String userInput = //read in user input
    Long id = Long.parseLong(userInput);
}catch(NumberFormatException e){
    id = 0; //recover the situation by setting the id to 0
}

1. Is the above considered a checked exception?

2. Is RuntimeException an unchecked exception?

Here is my understanding of an unchecked exception:

try{
    File file = new File("my/file/path");
    FileInputStream fis = new FileInputStream(file);   
}catch(FileNotFoundException e){

//3. What should I do here?
    //Should I "throw new FileNotFoundException("File not found");"?
    //Should I log?
    //Or should I System.exit(0);?
}

4. Now, couldn't the above code also be a checked exception? I can try to recover the situation like this? Can I? (Note: my 3rd question is inside the catch above)

try{
    String filePath = //read in from user input file path
    File file = new File(filePath);
    FileInputStream fis = new FileInputStream(file);   
}catch(FileNotFoundException e){
    //Kindly prompt the user an error message
    //Somehow ask the user to re-enter the file path.
}

5. Why do people do this?

public void someMethod throws Exception{

}

Why do they let the exception bubble up? Isn't handling the error sooner better? Why bubble up?

6. Should I bubble up the exact exception or mask it using Exception?

Below are my readings

In Java, when should I create a checked exception, and when should it be a runtime exception?

When to choose checked and unchecked exceptions

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

夕嗳→ 2024-11-16 19:05:51

以上是否被认为是受检查的异常？
不
如果您正在处理异常，但如果它是 RuntimeException，则不会使其成为 Checked Exception。
RuntimeException 是未经检查的异常吗？
是的

受检异常是java.lang.Exception的子类
Unchecked Exceptions 是 java.lang.RuntimeException 的子类

引发已检查异常的调用需要包含在 try{} 块中或在级别中处理上面在方法的调用者中。在这种情况下，当前方法必须声明它抛出所述异常，以便调用者可以做出适当的安排来处理异常。

希望这有帮助。

问：我应该冒出确切的信息吗？
异常或使用异常屏蔽它？

答：是的，这是一个非常好的问题，也是重要的设计考虑因素。 Exception 类是一个非常通用的异常类，可用于包装内部低级异常。您最好创建一个自定义异常并将其包装在其中。但是，还有一个大问题——永远不要掩盖根本原因。例如，永远不要执行以下操作 -

try {
     attemptLogin(userCredentials);
} catch (SQLException sqle) {
     throw new LoginFailureException("Cannot login!!"); //<-- Eat away original root cause, thus obscuring underlying problem.
}

相反，执行以下操作：

try {
     attemptLogin(userCredentials);
} catch (SQLException sqle) {
     throw new LoginFailureException(sqle); //<-- Wrap original exception to pass on root cause upstairs!.
}

消除原始根本原因会掩盖无法恢复的实际原因，这对于生产支持团队来说是一场噩梦，因为他们只能访问应用程序日志和错误消息。
虽然后者是一个更好的设计，但很多人不经常使用它，因为开发人员无法将底层消息传递给调用者。因此请牢记：无论是否包含在任何应用程序特定的异常中，始终传递实际的异常。

关于尝试捕获RuntimeExceptions

，作为一般规则，不应尝试捕获 RuntimeException。它们通常表示编程错误，应该不要管。相反，程序员应该在调用某些可能导致 RuntimeException 的代码之前检查错误条件。例如：

try {
    setStatusMessage("Hello Mr. " + userObject.getName() + ", Welcome to my site!);
} catch (NullPointerException npe) {
   sendError("Sorry, your userObject was null. Please contact customer care.");
}

这是一种不好的编程习惯。相反，应该进行空检查，例如 -

if (userObject != null) {
    setStatusMessage("Hello Mr. " + userObject.getName() + ", Welome to my site!);
} else {
   sendError("Sorry, your userObject was null. Please contact customer care.");
}

但有时此类错误检查的成本很高，例如数字格式，请考虑这一点 -

try {
    String userAge = (String)request.getParameter("age");
    userObject.setAge(Integer.parseInt(strUserAge));
} catch (NumberFormatException npe) {
   sendError("Sorry, Age is supposed to be an Integer. Please try again.");
}

这里预调用错误检查不值得付出努力，因为它本质上意味着复制所有字符串 - parseInt() 方法内的整数转换代码 - 如果由开发人员实现，则容易出错。所以最好还是取消 try-catch。

因此，NullPointerException 和 NumberFormatException 都是 RuntimeException，捕获 NullPointerException 应该用优雅的 null 检查替换，而我建议显式捕获 NumberFormatException 以避免可能引入容易出错的代码。

Is the above considered to be a checked exception?
No
The fact that you are handling an exception does not make it a Checked Exception if it is a RuntimeException.
Is RuntimeException an unchecked exception?
Yes

Checked Exceptions are subclasses of java.lang.Exception
Unchecked Exceptions are subclasses of java.lang.RuntimeException

Calls throwing checked exceptions need to be enclosed in a try{} block or handled in a level above in the caller of the method. In that case the current method must declare that it throws said exceptions so that the callers can make appropriate arrangements to handle the exception.

Hope this helps.

Q: should I bubble up the exact
exception or mask it using Exception?

A: Yes this is a very good question and important design consideration. The class Exception is a very general exception class and can be used to wrap internal low level exceptions. You would better create a custom exception and wrap inside it. But, and a big one - Never ever obscure in underlying original root cause. For ex, Don't ever do following -

try {
     attemptLogin(userCredentials);
} catch (SQLException sqle) {
     throw new LoginFailureException("Cannot login!!"); //<-- Eat away original root cause, thus obscuring underlying problem.
}

Instead do following:

try {
     attemptLogin(userCredentials);
} catch (SQLException sqle) {
     throw new LoginFailureException(sqle); //<-- Wrap original exception to pass on root cause upstairs!.
}

Eating away original root cause buries the actual cause beyond recovery is a nightmare for production support teams where all they are given access to is application logs and error messages.
Although the latter is a better design but many people don't use it often because developers just fail to pass on the underlying message to caller. So make a firm note: Always pass on the actual exception back whether or not wrapped in any application specific exception.

On try-catching RuntimeExceptions

RuntimeExceptions as a general rule should not be try-catched. They generally signal a programming error and should be left alone. Instead the programmer should check the error condition before invoking some code which might result in a RuntimeException. For ex:

try {
    setStatusMessage("Hello Mr. " + userObject.getName() + ", Welcome to my site!);
} catch (NullPointerException npe) {
   sendError("Sorry, your userObject was null. Please contact customer care.");
}

This is a bad programming practice. Instead a null-check should have been done like -

if (userObject != null) {
    setStatusMessage("Hello Mr. " + userObject.getName() + ", Welome to my site!);
} else {
   sendError("Sorry, your userObject was null. Please contact customer care.");
}

But there are times when such error checking is expensive such as number formatting, consider this -

try {
    String userAge = (String)request.getParameter("age");
    userObject.setAge(Integer.parseInt(strUserAge));
} catch (NumberFormatException npe) {
   sendError("Sorry, Age is supposed to be an Integer. Please try again.");
}

Here pre-invocation error checking is not worth the effort because it essentially means to duplicate all the string-to-integer conversion code inside parseInt() method - and is error prone if implemented by a developer. So it is better to just do away with try-catch.

So NullPointerException and NumberFormatException are both RuntimeExceptions, catching a NullPointerException should replaced with a graceful null-check while I recommend catching a NumberFormatException explicitly to avoid possible introduction of error prone code.

了解 Java 中的检查异常与非检查异常

如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

评论（21）

关于作者

相关话题

热门标签

推荐作者

留蓝

18790681156

zach7772

Wini

ayeshaaroy

初雪

友情链接

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。