您是为特定问题编写例外情况还是一般例外情况？

StackOverflow https://stackoverflow.com/questions/21652

  •  09-06-2019
  •  | 
  •  

题

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

emailUtil.sendEmail(userId, "foo");

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

MailException 可能会由于多种原因而抛出，例如电子邮件地址问题、邮件模板问题等。

我的问题是这样的：您是否为每个异常创建一个新的异常类型，然后单独处理它们，或者创建一个 MailException，然后在异常中存储一些内容（计算机可读的内容，而不是描述文本），以便我们可以执行不同的操作根据实际发生的情况。

编辑： 作为澄清，异常不适用于日志等，这与代码对它们的反应方式有关。继续以邮件为例，假设当我们发送邮件时，可能会因为您没有电子邮件地址而失败，或者可能因为您没有电子邮件地址而失败。 有效的 电子邮件地址，否则可能会失败..ETC。

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

最好为这些问题中的每一个问题都有一个异常实现，或者一个具有内部某些内容（例如枚举）的伞形异常，让代码区分它是什么类型的问题。

有帮助吗？

解决方案

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

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

这样你就可以获得两者的优点，你就没有像这样的抛出子句：

throws SpecificException1, SpecificException2, SpecificException3 ...

将军

throws GeneralException

足够。但如果你想对特殊情况做出特殊反应，你总是可以捕获特定的异常。

其他提示

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

有时，我确实想捕获特定的异常（正如您似乎想要做的那样）。然而，您可能会发现这种情况有点罕见，并且它表明使用异常来控制逻辑——这是低效（缓慢）并且经常令人不悦的。

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

公共 bool isEmailConfigured()

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

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

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

@克里斯·莱弗利

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

我发现，如果您需要让代码根据返回的异常决定要做什么，请创建一个命名良好的异常，子类化公共基类型。所传递的信息应被视为“仅限于人眼”，并且太脆弱而无法做出决定。让编译器来完成工作！

如果您需要通过不知道已检查异常的机制将其传递到更高层，则可以将其包装在 RuntimeException (MailDomainException) 的合适命名子类中，该子类可以捕获高层，并根据原始原因采取行动。

这取决于您的应用程序正在做什么。您可能想在以下情况下抛出个别异常

  • 该应用程序具有高可用性
  • 发送电子邮件尤为重要
  • 应用范围较小，发送电子邮件占很大一部分
  • 该应用程序将部署到远程站点，您只会获得用于调试的日志
  • 您可以从 mailException 中封装的异常的某些子集中恢复，但不能从其他异常中恢复

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

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

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

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

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

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

然后，调用代码将决定哪些要过滤到 UI，哪些要自行处理。

就我个人而言，我认为异常仅适用于无法实现正常代码解决方案的情况。性能打击和操作限制对我来说有点太多了。

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

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

更新： 合并答案

@乔纳森：我的观点是，我可以评估该操作，在本例中发送电子邮件，并发回多个失败原因。例如，“错误的电子邮件地址”、“空白邮件标题”等。

但有一个例外，您只能解决一个问题，然后要求用户重新提交，此时他们会发现第二个问题。这是一个非常糟糕的 UI 设计。

重新发明轮子..可能。然而，大多数应用程序应该分析整个事务，以便为用户提供尽可能最好的信息。想象一下，如果您的编译器在第一个错误时停止运行。然后修复错误并再次点击编译，结果却因不同的错误而再次停止。屁股多么痛啊。对我来说，这正是引发异常的问题，因此我说要使用不同的机制。

我倾向于使用较少的异常类型，尽管这并不是真正的面向对象方法。相反，我将一个枚举放入自定义异常中，对异常进行分类。大多数时候，我有一个自定义的基本异常，它保留几个成员，可以在派生的异常类型中重写或自定义这些成员。

几个月前我 写博客 关于如何国际化异常的想法。它包括上面提到的一些想法。

虽然您可以区分代码执行，但无论异常是通过“catch exceptionType 层次结构模式”还是通过“if(...) else...异常代码模式”完成，都无关紧要。

但是，如果您正在开发将被其他人使用的软件，例如一个库，我认为创建您自己的异常类型以通知其他人您的软件可以抛出除正常异常之外的其他异常是有用的，并且他们最好捕获和解决它们。

当我使用库及其方法只是启动“异常”时，我总是想知道：什么会导致此异常？我的程序必须如何反应？如果有 javadoc 也许会解释原因，但有时肯定没有 javadoc 或者未解释异常。使用 WellChossenExceptionTypeName 可以避免过多的开销

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

我就过去

throw new exception("WhatCausedIt")

如果您想处理异常，您可以传递代码而不是“WhatCausedIt”，然后使用 switch 语句对不同的答案做出反应。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top