您是否针对特定问题或一般例外编写例外情况？
我有一些代码为用户提供用户ID，然后向该用户发送电子邮件。
emailUtil.sendEmail(userId, "foo"); public void sendEmail(String userId, String message) throws MailException { /* ... logic that could throw a MailException */ } 可能由于多种原因而抛出MailException ，电子邮件地址出现问题，邮件模板出现问题等。
我的问题是：你是为这些exception中的每一个创建一个新的exception类型，然后单独处理它们，还是创建一个MailException，然后在exception中存储一些东西（计算机可读的东西，而不是描述文本）我们根据实际发生的事情做不同的事情。
编辑：作为澄清，例外不是日志和什么不是，这与代码如何反应它们有关。 为了继续使用邮件示例，让我们说当我们发送邮件时，它可能会因为您没有电子邮件地址而失败，或者因为您没有有效的电子邮件地址，或者可能会失败等等。
我的代码希望对每个问题做出不同的反应（主要是通过更改返回给客户端的消息，但也包括实际逻辑）。
最好是针对这些问题中的每一个进行exception实现，还是一个具有内部特征的一个伞状exception（枚举说），让代码区分它是什么类型的问题。
我通常从一般exception开始，并根据需要对其进行子类化。 如果需要，我总是可以捕获一般exception（以及所有子类exception），但也具体。
Java-API的一个例子是IOException，它有类似FileNotFoundException或EOFException（以及更多）的子类。
这样你就可以获得两者的优点，你没有像以下那样的throw-clauses：
throws SpecificException1, SpecificException2, SpecificException3 ...
将军
throws GeneralException
足够。 但是，如果您想对特殊情况做出特殊反应，您可以随时捕获特定的exception。
在我的代码中，我发现MOSTexception渗透到UI层，在那里它们被我的exception处理程序捕获，它只是向用户显示一条消息（并写入日志）。 毕竟，这是一个意想不到的例外。
有时，我确实希望捕获一个特定的exception（正如您似乎想要做的那样）。 但是，您可能会发现这种情况有点罕见，并且它表明使用exception来控制逻辑 – 效率低（慢）且经常不赞成。
因此，使用您的示例，如果您想在未配置电子邮件服务器时运行某些特殊逻辑，您可能需要向emailUtil对象添加一个方法，如：
public bool isEmailConfigured（）
…先调用它，而不是寻找特定的exception。
当发生exception时，它实际上意味着情况完全出乎意料并且代码无法处理它 – 所以您可以做的最好的事情是将其报告给用户（或将其写入日志或重新启动）
至于具有exception层次结构与其中的exception错误代码，我通常会执行后者。 如果您只需要定义新的错误常量而不是全新的类，则更容易添加新的exception。 但是，只要您尝试在整个项目中保持一致，这并不重要。
@ Chris.Lively
您知道可以在exception中传递消息，甚至可以传递“状态代码”。 你在这里重新发明轮子。
我发现如果你需要根据返回的exception让CODE决定做什么，那么创建一个名为exception的exception子类化公共基类型。 传递的信息应该被视为“只有人眼”而且太脆弱而无法做出决定。 让编译器完成工作！
如果需要通过不知道已检查exception的机制将其传递给更高层，则可以将其包装在RuntimeException（MailDomainException）的合适命名子类中，该子类可以被捕获，并且原始原因可以作用。
这取决于您的应用程序正在做什么。 您可能希望在类似的情况下抛出个别exception
- 该应用程序是高可用性
- 发送电子邮件尤为重要
- 应用程序的范围很小，发送电子邮件是其中很大一部分
- 应用程序将部署到远程站点，您只能获取调试日志
- 您可以从mailException中封装的exception的某些子集中恢复，但不能从其他exception中恢复
在大多数情况下，我会说只记录exception的文本，并且不要浪费你的时间来细化已经非常精细的exception。
我认为上述的组合会给你最好的结果。
您可以根据问题抛出不同的exception。 例如，缺少电子邮件地址= ArgumentException。
但是在UI层中，您可以检查exception类型，如果需要，还可以检查消息，然后向用户显示相应的消息。 如果抛出某种类型的exception（我的应用程序中的UserException），我个人倾向于只向用户显示信息性消息。 当然，您应该尽可能地在堆栈中进行擦除和validation用户输入，以确保在真正不太可能的情况下生成任何exception，而不是作为可以使用正则表达式轻松检查的格式错误的电子邮件的filter。
我也不担心从用户输入中捕获exception的性能影响。 您唯一能够从exception中看到性能问题的时候是它们被抛出并陷入循环或类似情况。
我倾向于从可能执行问题的方法返回状态对象列表，而不是使用exception。 状态对象包含严重性枚举（信息，警告，错误，…）状态对象名称，如“电子邮件地址”和用户可读消息，如“格式错误的电子邮件地址”
然后，调用代码将决定向UI过滤哪个以及自己处理哪个。
就个人而言，我认为当你无法实现正常的代码解决方案时，例外是严格的。 性能损失和处理限制对我来说有点太多了。
使用状态对象列表的另一个原因是识别多个错误（例如在validation期间）更容易。 毕竟，你只能抛出一个必须在继续之前处理的exception。
想象一下，用户提交的电子邮件的目的地地址格式错误，并且包含您要阻止的语言。 您是否抛出格式错误的电子邮件exception，然后，在他们修复并重新提交之后，抛出错误的语言exception？ 从用户体验的角度来看，同时处理所有这些问题是一种更好的方法。
更新：结合答案
@Jonathan：我的观点是我可以评估该操作，在这种情况下发送电子邮件，并发回多个失败原因。 例如，“错误的电子邮件地址”，“空白邮件标题”等。
除了一个例外，你仅限于渗透一个问题，然后要求用户重新提交，在那一点上他们发现第二个问题。 这是非常糟糕的UI设计。
重新发明轮子..可能。 但是，大多数应用程序应分析整个事务，以便为用户提供最佳信息。 想象一下，如果你的编译器在第一个错误时停止了死机。 然后你修复错误并再次点击编译，让它再次停止以获得不同的错误。 屁股上有多痛。 对我来说，这正是抛出exception的问题，因此我说使用不同机制的原因。
我倾向于使用更少的exception类型，尽管它不是真正的OO方式。 相反，我将枚举放到我的自定义exception中，该exception将exception分类。 大多数情况下，我有一个自定义基础exception，它保留了几个成员，可以在派生的exception类型中覆盖或自定义。
几个月前，我在博客上写了关于如何使例外国际化的想法。 它包括上面提到的一些想法。
虽然您可以区分代码执行，但查看exception并不重要，如果它是由“catch exceptionType hierarchy mode”或“if（…）else … exception code mode”完成的
但是如果你正在开发其他人会使用的软件，比如一个库，我认为创建你自己的exception类型是有用的，可以注意到其他人你的软件可以抛出除正常之外的其他exception，并且它们更好地捕获并且解决他们。
当我使用一个库并且他们的方法只是启动一个’exception’我总是想知道：什么可以导致这个exception？，我的程序必须如何反应？，如果有一个javadoc可能会解释原因，但必须有时间不是javadoc或没有解释exception。 使用WellChossenExceptionTypeName可以避免过多的开销
这取决于捕获exception的代码是否需要区分exception，或者您是否只是使用exception来失败到错误页面。 如果需要区分NullReferenceexception和调用堆栈中更高的自定义MailException，请花时间并编写它。 但是大多数时候程序员只是使用exception来捕获所有在网页上抛出错误。 在这种情况下，您只是在浪费精力编写新的exception。
我会过去的
throw new exception("WhatCausedIt")
如果你想处理你的例外，你可以传递代码而不是“WhatCausedIt”，然后用switch语句对不同的答案作出反应。