捕获更一般类型的exception是否好？

如果我们要捕获特定forms的IOException ，或事实上任何其他forms，我们只尝试捕捉一对（并为它们定义确定的输出）说

FileNotFoundException
ZipException

我们是否应该总是把它用掉，用一个盖住所有的基地

 catch(IOException e){ e.printStackTrace(); }

然后可能更进一步捕捉Exception e ，还是完全浪费时间？

通常，您只想捕获并处理可以在较低级别执行某些操作的exception。然后在更高级别捕获任何未处理的系统范围exception，以便您可以记录发生的错误。

通常，您应该只捕获要明确处理的exception。

你不应该捕获Exception，IOException等。 al。，除非你是一个适当的高级别，你正在做你的最后一次捕获，向用户报告一般错误。

如有疑问，请始终抓住更具体的例外！

您正在捕获的exception层次越高，并且没有正确处理它们或重新抛出，您将在地毯下面遇到的问题就越多。您可以拥有难以跟踪的无声错误。

因此，只捕获适当的例外，并让其他人通过。在顶层，如果你不想让你的程序崩溃，你可以拥有一个catch，但至少记录它。这仍然是一个值得怀疑的方法，因为您的应用程序可能处于不一致状态，并且您可能会损坏您的数据。

但是要直接回答您的问题，IOException可能处于适当的级别。它可能足以让你知道无论问题是什么，它都与IO有关，你可以按照它行事。没有更多信息，很难说。

茫然地捕捉任何exception并不是一个好主意。是的，作为父exception，它似乎提供了一层“保护”，但这有几个原因：

检查IOExceptions。如果在代码中没有任何地方抛出它，添加一个不需要的捕获只是模糊了一些东西，并且很可能会混淆以后查看代码的任何人。

更重要的是，你不会捕获exception，只是让它们消失。如果他们这样做了，你可以将所有方法包装在（catch（Exception e）{..}）中并完成它。您的exception捕获代码应该是您决定在发生这些错误时该怎么做的地方，例如

 catch(FileNotFoundException e) { log.error("where's the file?");return null; } catch(ZipException e) { log.error("corrupt");return null; }

关键是要使该方法在所有可能的条件下都表现良好。然后，呼叫者处理文件内容或没有内容，而不用担心内容是如何到达那里的。

像一位好顾问一样，我说“这取决于”。

通常在Java中，您可以清楚地了解代码中特定点的所有可能exception。看到有人使用它并不罕见

 } catch (Exception e){ // log or stack trace }

…或多或少的一次性代码。但是，一般情况下，您不应该捕获一个您不知道如何有效处理的exception。（从来没有，永远不会 catch (Exception x) ;即，只是扔掉exception。从不。）

控制的是问“我该怎么做？” 通常，可以通过询问用户文件的去向来处理文件而不是exception。 zip文件exception更难处理。因此，您可能希望拥有单独的行为。

另一方面，如果它是一个命令行程序，在任何一种情况下，您可能只需要一条错误消息。

另外一点建议; 不要在“cutomer facing”代码中输出堆栈跟踪 – 非程序员可能看到的代码。非程序员倾向于查看堆栈跟踪和恐慌的完整性。最好将exception转换为“找不到文件’文件名’这样的消息。” 并且，如果您确实需要堆栈跟踪，请将日志记录发送到调试级别输出。

我认为这是个人喜好的问题。就个人而言，这似乎不是一个好的选择。我更喜欢使用try-catch的东西让代码对我有意义。这意味着尽可能具体。我会说：

 try{ //Code Here } catch(FileNotFoundException e){ //Code Here }

您不应该在可能发生IOException的每个可能位置捕获这些，而是在您准备处理剩余IOExceptions和常规exception的调用树中进一步。

我们使用经验法则，您可以在可以处理错误的位置捕获特定的exception，并将剩余的exception传递给调用者。

我会回应“抓住你能找到的最具体的例外”。

我经常捕获IOException并显示某种“错误读取文件”消息，然后允许用户选择另一个文件或任何合适的文件。如果文件非常糟糕，那么用户可能无法做到这一点，但至少你可以让他们知道文件是坏的。

如果你得到一个FileNotFoundException，真正的问题几乎肯定是用户选择了错误的文件名或硬编码的文件名不再有效。我经常为此显示消息。

我几乎从不捕捉“例外”。你打算怎么办呢？你可以做的就是从“出了问题但没有更多细节可用”中恢复过来。在某些情况下，我认为你至少可以显示错误信息，而不仅仅是死亡，但这就是它。

这取决于更具体的例外是否有助于解决问题。有时候，就像使用JMX一样，它很好地捕获父exception以避免可能的子exception的长列表。至少Java 7将允许我们每次捕获更多的例外。这将清理代码相当多。