这种 Java 异常风格是不好的做法吗？答案

【问题标题】：Is this sort of Java exception style bad practice?这种 Java 异常风格是不好的做法吗？
【发布时间】：2010-02-23 08:46:26
【问题描述】：

在一种方法中多次尝试并像这样构造代码是否被认为是不好的做法？

public void whatever() {
   try {
     methodThatMayThrowIOException();
   } catch(IOException io) {
     // do something with exception here
   }

   // do more stuff here that won't throw exceptions

   try {
     methodThatMayThrowCustomException();
   } catch(CustomException ce) {
     // do something with custom exception here
   }
}

【问题讨论】：

为什么应该是一个不好的做法？似乎是有序的（我的意思是，你只在必须的地方赶上）。我唯一会考虑的是在whatever 之外抛出异常，因为我更喜欢抛出异常并越早看到错误越好（只在表示层捕获异常）。
如果不了解更多细节，就无法回答这个问题。如果 IOException 可以恢复，那就是好风格，如果不能，那就是非常糟糕的风格。
IOException 只是一个例子。我想知道一种方法中的多次尝试。

标签： java exception coding-style

【解决方案1】：

如果方法可以继续执行，即使发生指定的异常也没有任何问题。

如果异常应该在方法中进一步导致问题，我会让它冒泡。

【讨论】：

【解决方案2】：

不，不是。捕获可能抛出的特定异常是一个好点，恕我直言，这肯定比这更好：

public void whatever {
    try {
        methodThatMayThrowIOException();
        // do more stuff here that won't throw exceptions
        methodThatMayThrowCustomException();
    } catch(ParentException e) {
        // do something with custom exception here
    }
}

【讨论】：

如果在 methodThatMayThrowIOException() 抛出异常并处理后，methodThatMayThrowCustomException() 可以正常工作，这会更糟吗？
此外，在示例中，完全不确定 IOException 和 CustomException 是否有共同的父级（Exception 除外，但捕获 Exception 不是一个好主意）
@Thomas Lötzer：什么？如果methodThatMayThrowIOException() 抛出异常，则methodThatMayThrowCustomException() 根本不会被执行...如果您在方法中谈论try catch，那么您就是在做出假设，这超出了我认为的问题范围。 @Valentin Rocher：没有找到共同的父母（即使那只是例外），正是我回答的重点。
好的，我看错了你的答案。你能做一个虚拟编辑，让我删除反对票吗？
好的，我自己做了一个虚拟编辑，并删除了反对票。对不起！

【解决方案3】：

您的代码看起来像这样，因为您想要执行第 1 部分（并解析，如有必要，捕获 IOException），执行无异常部分，然后执行 methodThatMayThrowCustomException。 您的代码实际上不能以任何其他方式编写并保留相同的功能。这有点夸张，但任何其他版本在表面上都会有所不同。

这不相同：

public void whatever {
   try {
     methodThatMayThrowIOException();
     // do more stuff here that won't throw exceptions
     methodThatMayThrowCustomException();
   } catch(IOException io) {
     // do something with io exception here
   } catch(CustomException ce) {
     // do something with custom exception here
   }
}

如果抛出任何异常，它将执行的方式完全不同。如果您需要从第 1 部分顺序恢复，无论如何点击第 2 部分，然后继续第 3 部分，您无法真正以任何其他方式编写代码。

拥有两个 catch 块并没有什么问题，尽管将导致 IOException 的内容与引发 CustomException 的内容混合可能会暗示关注点的混合，从而使您的代码难以理解。但事实上，它不仅有效，而且是做你正在做的事情的唯一方法。

【讨论】：

他从来没有明确说过他无论如何都想打第二部。例如，//do something with io exception here 部分可以是 throw new WhateverException();，在这种情况下，多个 catch 块会做得很好并且更清晰。这就是我试图在我的回答中提出的观点：只有在他实际上利用他的方法允许他做更多事情的事实时才使用他的方法。否则，只需使用多个 catch 块的“较弱”（因此更容易理解）标准习语。

【解决方案4】：

看起来不错，但这取决于 methodThatMayThrowIOException 和 methodThatMayThrowCustomException 的操作以及第一个 (methodThatMayThrowIOException) 的失败是否应该使整个 whatever 方法失败。

【讨论】：

【解决方案5】：

如果抛出 IOException，这实际上取决于您打算做什么。您的风格允许您做更多的事情，但如果您实际上并不打算利用这一点，那么使用标准习语可以使您的意图更加清晰。

public void whatever {
   try {
     methodThatMayThrowIOException();
     // do more stuff here that won't throw exceptions
     methodThatMayThrowCustomException();
   } catch(IOException io) {
     // do something with io exception here
   } catch(CustomException ce) {
     // do something with custom exception here
   }
}

在这里您可以快速判断，如果抛出 IOException，那么您只执行 catch 块内的操作，而不会执行其他操作。

【讨论】：

他已经通过第二和第三部分来利用这一点。
是的，但是第一个 catch 块可以返回/抛出，或者它可以设置保护标志来阻止第二和第三部分的实际肉类和土豆执行，等等。
是的。我有点假设他在问“我的代码完全符合我的要求。这是一个坏主意吗？”但你是对的。它可能不会完全按照他的意愿行事。 +1

【解决方案6】：

我不明白为什么这是不好的做法，只要您确实对捕获的异常做一些有用的事情。

【讨论】：

【解决方案7】：

这没有问题，AFAICS。然而，2 try-catch in a method 刺伤了我的眼睛。如果你有同样的感觉，我建议你以适当的方式重构它。

【讨论】：

【解决方案8】：

没有。这是一个很好的做法，可以缩小引发某种异常的范围。我在代码中经常这样做。

但是，如果您确定在一个 try...catch 块中，某种异常只会由唯一的函数抛出，将它们放在同一个 try 块中也是可以的。

【讨论】：

【解决方案9】：

这取决于您要完成的工作。如果代码块应该作为一个块执行，或者如果发生某些异常，则根本不执行，您通常会将一个代码块包含在单个 try-catch 块中。如果不是这种情况，那么我相信最好隔离不同的代码块，将不同的异常抛出到不同的 try-catch 块中，“在这里做更多不抛出异常的事情”。只是一个想法！

【讨论】：

【解决方案10】：

就个人而言，我认为它看起来很混乱。我更喜欢只尝试一次，我需要尽可能多的 catch 块。我不在乎单个方法中的多个 try/catch 序列。

【讨论】：