Question

我有一些代码可以向实用程序提供用户ID，然后向该用户发送电子邮件。

emailUtil.sendEmail(userId, "foo");

public void sendEmail(String userId, String message) throws MailException {
    /* ... logic that could throw a MailException */
}

MailException可能会因为多种原因而被抛出，电子邮件地址出现问题，邮件模板出现问题等。

我的问题是：你是为这些异常中的每一个创建一个新的异常类型然后单独处理它们还是创建一个MailException然后在异常中存储一些东西（计算机可读的东西，而不是描述文本））它允许我们根据实际发生的事情做不同的事情。

编辑：作为澄清，例外不是针对日志而是针对什么不是，这与代码对它们的反应有关。为了继续使用邮件示例，让我们说当我们发送邮件时，它可能会因为您没有电子邮件地址而失败，或者因为您没有有效电子邮件地址，或者它可能会失败..等等。

我的代码希望对每个问题做出不同的反应（主要是通过更改返回给客户端的消息，但也包括实际逻辑）。

最好是针对这些问题中的每一个进行异常实现，还是一个具有内部特征的一个伞状异常（一个枚举说），让代码区分它是什么类型的问题。

Answer 1

在我的代码中，我发现MOST异常渗透到UI层，在那里它们被我的异常处理程序捕获，它只是向用户显示一条消息（并写入日志）。毕竟，这是一个意想不到的例外。

有时，我确实希望捕获一个特定的异常（正如您似乎想要做的那样）。但是，您可能会发现这种情况有点罕见，并且它表明使用异常来控制逻辑 - 效率低（慢）且经常不赞成。

因此，使用您的示例，如果您想在未配置电子邮件服务器时运行某些特殊逻辑，您可能需要向emailUtil对象添加一个方法，如：

public bool isEmailConfigured（）

...首先调用它，而不是寻找特定的异常。

当发生异常时，它实际上意味着情况完全出乎意料并且代码无法处理它 - 所以您可以做的最好的事情是将其报告给用户（或将其写入日志或重新启动）

至于具有异常层次结构与其中的异常错误代码，我通常会执行后者。如果您只需要定义新的错误常量而不是全新的类，则更容易添加新的异常。但是，只要您尝试在整个项目中保持一致，这并不重要。

Answer 2

我通常从一般异常开始，并根据需要对其进行子类化。如果需要，我总是可以捕获一般异常（以及所有子类异常），但也可以捕获特定的异常。

Java-API的一个例子是IOException，它有类似FileNotFoundException或EOFException（以及更多）的子类。

这样你就可以获得两者的优点，你没有像以下那样的throw-clauses：

throws SpecificException1, SpecificException2, SpecificException3 ...

一般

throws GeneralException

就够了。但是如果你想对特殊情况做出特殊反应，你总能抓住特定的例外。

Answer 3

@ Chris.Lively

您知道可以在异常中传递消息，甚至是“状态代码”。你在这里重新发明轮子。

Answer 4

我发现如果你需要根据返回的异常让CODE决定做什么，那么创建一个名为exception的异常子类化公共基类型。传递的信息应该被视为“只有人眼”而且太脆弱而无法做出决定。让编译器完成工作！

如果你需要通过一个不知道已检查异常的机制将它传递给更高层，你可以将它包装在RuntimeException（MailDomainException）的一个合适的命名子类中，该子类可以被捕获，并且原始原因可以作用于

Answer 5

这取决于您的应用程序正在做什么。您可能希望在

等情况下抛出个别异常

应用程序是高可用性
发送电子邮件特别重要
应用程序的范围很小，发送电子邮件是其中很大一部分
应用程序将部署到远程站点，您只能获取调试日志
您可以从mailException中封装的异常的某个子集中恢复，但不能从其他

在大多数情况下，我会说只记录异常的文本，不要浪费你的时间来细化已经非常细微的异常。

Answer 6

我倾向于从可能执行问题的方法返回状态对象列表，而不是使用异常。状态对象包含严重性枚举（信息，警告，错误，...）状态对象名称，如“电子邮件地址”和用户可读消息，如“格式错误的电子邮件地址”

然后，调用代码将决定过滤哪个UI以及自己处理哪个。

就个人而言，我认为当您无法实现正常的代码解决方案时，例外情况是严格的。性能损失和处理限制对我来说太过分了。

使用状态对象列表的另一个原因是识别多个错误（例如在验证期间）更容易。毕竟，您只能抛出一个必须在继续之前处理的异常。

想象一下，用户提交的电子邮件的目标地址格式错误，并且包含您要阻止的语言。您是否抛出了格式错误的电子邮件异常，然后，在他们修复并重新提交后，抛出一个错误的语言异常？从用户体验的角度来看，同时处理所有这些问题是一种更好的方法。

更新：合并答案

@Jonathan：我的观点是我可以评估行动，在这种情况下发送电子邮件，并发回多个失败原因。例如，“错误的电子邮件地址”，“空白邮件标题”等。

除了例外之外，您仅限于解决一个问题，然后要求用户重新提交，以便他们发现第二个问题。这是非常糟糕的UI设计。

重新发明轮子......可能。但是，大多数应用程序应分析整个事务，以便为用户提供最佳信息。想象一下，如果你的编译器在第一个错误时停止了死机。然后修复错误并再次点击编译，让它再次停止以获得不同的错误。屁股上有多痛苦。对我来说，这正是抛出异常的问题，因此我说使用不同机制的原因。

Answer 7

我认为上述的组合会给你最好的结果。

您可以根据问题抛出不同的异常。例如缺少电子邮件地址= ArgumentException。

但是在UI层中，您可以检查异常类型，如果需要，还可以检查消息，然后向用户显示相应的消息。如果抛出某种类型的异常（我的应用程序中的UserException），我个人倾向于仅向用户显示信息性消息。当然，您应该尽可能地在堆栈中进行擦除和验证用户输入，以确保在真正不太可能的情况下生成任何异常，而不是作为可以使用正则表达式轻松检查的格式错误的电子邮件的过滤器。

我也不担心从用户输入中捕获异常的性能影响。您唯一能够从异常中看到性能问题的时候是它们被抛出并陷入循环或类似的情况。

Answer 8

我倾向于使用更少的异常类型，尽管它不是真正的OO方式。相反，我把一个枚举放到我的自定义异常，它将异常分类。大多数情况下，我有一个自定义基础异常，它保留了几个成员，可以在派生的异常类型中覆盖或自定义。

几个月前，我blogged关于如何将例外国际化的想法。它包括上面提到的一些想法。

Answer 9

虽然您可以区分代码执行，但查看异常并不重要，如果它是由“catch exceptionType层次模式”或“if（...）else ...异常代码模式”完成的

但是如果你正在开发其他人会使用的软件，比如图书馆，我认为创建你自己的异常类型是有用的，可以注意到其他人你的软件可以抛出除正常之外的其他异常，并且他们更好地捕捉并解决它们。

当我使用一个库并且他们的方法只是启动一个'异常'我总是想知道：什么可以导致这个异常？，我的程序如何反应？，如果有一个javadoc可能会解释原因，但必须时间没有javadoc或没有解释异常。使用WellChossenExceptionTypeName

可以避免过多的开销

Answer 10

这取决于捕获异常的代码是否需要区分异常，或者您是否只是使用异常来失败到错误页面。如果需要在调用堆栈中区分NullReference异常和自定义MailException，请花时间并编写它。但是大多数时候程序员只是使用异常来捕获所有在网页上抛出错误。在这种情况下，您只是在浪费精力编写新的异常。

Answer 11

我会去

throw new exception("WhatCausedIt")

如果你想处理你的例外，你可以传递代码而不是“WhatCausedIt”，然后用switch语句对不同的答案作出反应。

您是否针对特定问题或一般例外编写例外情况？

11 个答案: