Question

我正在处理一个项目，我已经为每个可能的异常情况编写了一个Exception。关键是我觉得它更“可读”，但我得到了大量不同的例外。

这样做是否被认为是一种好习惯？或者，为了没有这么多，我应该将异常写得更抽象一些吗？

非常感谢你的时间。

Answer 1

哪个更好取决于您的代码捕获特定异常的可能性。如果你只是有可能捕获（或以某种其他方式区分）更一般的（超类）异常，那么拥有许多更具体的（子类）异常并没有实现太多。在这种情况下，最好定义更少的异常并使用异常消息来表达出错的更详细信息。

另一方面，如果已经存在特定的例外，则使用它们是有意义的。只是投掷java.lang.Exception或java.lang.RuntimeException是懒惰的，IMO。

关注

好吧，我总是抓住特定的异常，但事实是，在其他“捕获”中我也使用了类似的特定异常（例如，它们可以引用“数据库”，但它们不相同）。所以问题是，做一个“DatabaseException”应该是一件好事，并使用它，而不是“DatabaseConnectionException”和“DatabaseDataException”，例如，它更具可读性，但最后我得到了数以百万计的显式异常。 / p>

如果您的代码经常如下所示：

try {
    ... 
} catch (DatabaseConnectionException ex) {
    // do something
} catch (DatabaseDataException ex) {
    // do same thing
} catch (DatabaseTangoException ex) {
    // do same thing
}

...然后你的细粒度例外没有帮助。但如果它看起来像这样：

try {
    ... 
} catch (DatabaseConnectionException ex) {
    // do something
} catch (DatabaseDataException ex) {
    // do something completely different
} catch (DatabaseTangoException ex) {
    // do something totally extraordinary
}

...那么也许你的细粒度例外对你有用。如果您将这三个例外声明为DatabaseDataException的子类，那么您可以根据具体情况一起或单独处理这些案例。

实际上，您可以根据申请做出自己的判断。

Answer 2

我建议使用抽象的DomainException（其中domain反映了您的组织或问题所在的应用程序层），所有特定的例外都会扩展。

然后你可以捕获DomainException来说这是你的代码的问题，然后在需要时进行优化。

Answer 3

Bloch, J., 2008. Effective Java. 2nd ed：

第60项：赞成使用标准例外

重用先前存在的例外情况   几个好处。其中最主要的是，   它使您的API更容易学习和   使用，因为它匹配已建立   程序员的惯例   已经熟悉了。紧随其后的是   使用您的API的程序是   更容易阅读，因为他们不是   杂乱的陌生例外。   最后（和最少），更少的例外   类意味着更小的内存   足迹和更少的装载时间   类。

Answer 4

你可以扩展异常并不意味着你应该。 Dogbane的回答给出了使用标准异常的充分理由。（请注意，他说使用“标准”异常，而不是“通用”！尽可能使用标准异常。）

我认为只有在以下两个条件都为真时才应使用自己的异常子类：

当你遇到某类异常时，你想做一些具体的事情;在这种情况下使用特定的子类可以让你捕获它，同时让其他异常冒泡而没有问题。
没有足够准确的标准例外涵盖您的类别。

Answer 5

为什么不创建少量异常并让它们在构造函数中使用描述性字符串？

throw new GenericException("Error: problem with....");

让toString（）方法打印出你传递的字符串。

Answer 6

我认为尽可能使用特定的例外是一种很好的做法。

通过遵循这种做法，我们根据异常类型提供不同的错误消息。

即使像Java这样的编程语言也支持这个概念，允许程序员extend Exception类并创建自己的Exception子类。

您也可以从以下问题获得更多信息。 Exception Handling Question

对所有事情都有特定的例外是一个好习惯吗？或者重用一些更抽象的异常更好？

6 个答案: