问题标签 [checked-exceptions]

在 Java（或任何其他具有检查异常的语言）中，当创建自己的异常类时，您如何决定是否应该检查或不检查？

我的直觉是，在调用者可能能够以某种有效的方式恢复的情况下，会调用检查异常，而对于不可恢复的情况，未经检查的异常会更多，但我会对其他人的想法感兴趣。

我在java中有这个工厂方法：

我想将两个已检查的异常转换为未检查的异常。解决此问题的最佳方法是什么？

我应该只捕获异常并使用捕获的异常作为内部异常抛出一个新的 RuntimeException 吗？

有没有更好的方法来做到这一点，或者我什至应该首先尝试这样做？

编辑：
只是为了澄清。这些异常将是致命的，因为配置文件本质上是程序的操作，所有异常都将被捕获并记录在我的程序的顶层。

我的目的是避免不必要的抛出异常，将异常添加到调用我的工厂的每个方法的签名中。

多年来，我一直无法得到以下问题的正确答案：为什么有些开发人员如此反对受检异常？我进行了无数次对话，阅读了博客上的内容，阅读了布鲁斯·埃克尔（Bruce Eckel）所说的话（我看到的第一个反对他们的人）。

我目前正在编写一些新代码，并非常注意我如何处理异常。我试图看到“我们不喜欢检查异常”人群的观点，但我仍然看不到它。

我的每一次谈话都以同样的问题结束……让我来设置一下：

一般来说（从 Java 的设计方式来看），

• Error用于永远不应该被抓住的东西（VM 对花生过敏，有人在上面掉了一罐花生）
• RuntimeException是针对程序员做错的事情（程序员离开了数组的末尾）
• Exception（除了RuntimeException）是程序员无法控制的事情（写入文件系统时磁盘已满，已达到进程的文件句柄限制，您无法打开更多文件）
• Throwable只是所有异常类型的父级。

我听到的一个常见论点是，如果发生异常，那么开发人员要做的就是退出程序。

我听到的另一个常见论点是检查异常使重构代码变得更加困难。

对于“我要做的就是退出”的论点，我说即使您要退出，您也需要显示合理的错误消息。如果您只是在处理错误，那么当程序退出而没有明确说明原因时，您的用户不会过分高兴。

对于“重构变得困难”的人群，这表明没有选择适当的抽象级别。而不是声明一个方法抛出一个IOException，IOException应该将其转换为一个更适合正在发生的事情的异常。

我对 Main 包装没有问题catch(Exception)（或者在某些情况下catch(Throwable)确保程序可以正常退出 - 但我总是捕获我需要的特定异常。这样做至少可以让我显示一个适当的错误信息。

人们从不回答的问题是：

如果你抛出RuntimeException 子类而不是Exception 子类，那么你怎么知道你应该捕获什么？

如果答案是catch Exception，那么您也将像处理系统异常一样处理程序员错误。这对我来说似乎是错误的。

如果你抓住Throwable了，那么你就会以同样的方式处理系统异常和 VM 错误（等等）。这对我来说似乎是错误的。

如果答案是你只捕获你知道抛出的异常，那么你怎么知道抛出了什么？当程序员 X 抛出一个新异常并忘记捕获它时会发生什么？这对我来说似乎很危险。

我会说显示堆栈跟踪的程序是错误的。不喜欢检查异常的人不会有这种感觉吗？

所以，如果你不喜欢检查的异常，你能解释一下为什么不回答没有得到回答的问题吗？

我不是在寻找关于何时使用这两种模型的建议，我正在寻找的是为什么人们RuntimeException因为不喜欢从扩展而扩展Exception和/或为什么他们捕获异常然后重新抛出 aRuntimeException而不是在他们的方法中添加抛出. 我想了解不喜欢检查异常的动机。

有人告诉我，在 Java 中，未检查的异常可以在 try 块中捕获，但如果它被捕获，它不称为检查异常吗？

可能重复：
何时选择已检查和未检查的异常

你好！

因此，我仍然对何时抛出已检查或未检查的异常感到满意。我想知道在这种情况下其他人认为最合适的是：

因此，在这种情况下，我想抛出一个运行时异常，因为我无法轻易地从用户传入错误数据的情况中恢复过来。我想事先指出，我无法控制传入的数据。如果可以的话，我会创建一个接口来保证构造函数中的条件为真。但是，对于已经计算过的相关性来说，这是一个便利类，所以我必须相信用户提供了准确的信息。

好吧，让我知道你们的想法！

为什么让 Runtime Exceptions UnChecked 有意义（而不是Checked）？

在 .NET 中，方法签名不会告诉我是否错过了处理一些可能由我的代码引发的异常。如果说我正在使用 HashTable 删除但尚未处理 ArgumentNullException，是否有一些工具可以警告我？我不想在运行时感到惊讶。

这是否意味着您需要非常了解您的代码，否则未经检查的异常可能更难处理？

在阅读异常时，我总是会遇到已检查的异常和未检查的异常，所以想知道如何区分哪个是什么？

编辑：我想知道我是否创建了任何异常类，那么我如何创建为已选中或未选中？

每个的意义是什么？

I know that Java enforce the programmer to list all exceptions that will be thrown by the method, and thus creating an easy way of listing all possible thrown exception for the user of code.

.NET on the other hand has no such feature, and all we're left with is the API documentation or XML documentation where the exceptions are sometimes listed.

Is there any addons for VS that shows which exceptions any given call might throw? Given the power of reflection, shouldn't it be possible to look through the call, and look through all branches of possible runs through the call and check for any .NET exceptions being thrown?

我有一个异常链，其中method1抛出一个异常method2，将异常抛出到main. 出于某种原因，编译器强制我处理错误，method2如果我不这样做，则将其标记为错误，表明这是一个已检查的异常。但是，当同样Exception的内容被进一步抛出时main，编译器允许我忽略它并且不显示任何错误。

中的原始异常method1是 a ParseException，已检查。但是该方法在头中有一个通用throws Exception子句，并且将相同的对象抛出给具有相同throws Exception子句的method2。这个异常何时以及如何失去被编译器检查/捕获的状态？

编辑澄清：

编辑： 对不起大家，这个问题是基于一个错误......主要方法实际上有一个throws Exception我错过的子句。我已经删除了它，代码现在按预期运行。感谢所有的帮助！