何时使用自定义异常 [重复]答案

【问题标题】：When to use custom exception [duplicate]何时使用自定义异常 [重复]
【发布时间】：2013-10-23 20:48:37
【问题描述】：

可能重复：
Create custom exception or use built-in exceptions?

嗨，

在程序设计中，为业务约束建模异常是否正常？例如。如果 xyz 必须大于 1 才能获得 abc（篮子对象必须存在才能添加对象），并且篮子不存在，这是有足够好的理由使用自定义异常来模拟这个真实场景吗?

使用自定义异常的原因有哪些？

【问题讨论】：

【解决方案1】：

我认为问题不在于是否应该创建自定义异常类，而是是否应该在输入错误的正常情况下使用异常，即如果您要求用户创建新密码，代码内部是否应该抛出 PasswordTooWeakException (或 InvalidArgumentException) 当密码太弱时，或者应该以其他方式处理它。如果这是问题，我的回答是否定的，在这种情况下你不应该使用例外。例外仅适用于 exception 情况，即发生意外情况的错误情况。

【讨论】：

【解决方案2】：

如果篮子不存在，则听起来像ArgumentNullException 或InvalidOperationException，具体取决于变量是否为参数。如果 xyz 必须大于 1，听起来像 ArgumentException。后一种情况听起来您也可以处理根据验证发生的位置诉诸异常。

作为标准库的一部分，已经定义了许多异常。我的建议是依赖这些，直到您可以清楚地证明此类例外确实不涵盖您的特定场景。

【讨论】：

你几乎不应该抛出 NullReferenceException。它非常具体——当取消引用 null 时会抛出它。对于其他用途，ArgumentNullException 或 InvalidOperationException 更合适。

【解决方案3】：

当我计划区别对待它们（或认为它们应该区别对待）时，我会使用自定义异常。在许多情况下，带有好消息的一般异常就足够了。

如果您打算在 catch 中做的只是显示消息，那么您不会从自定义异常中获得太多收益。

【讨论】：

一个很好的例子是 cardoesntstartexception，当汽车需要启动以执行其预期任务的方法时。此外，实际捕获非常不可能的异常/处理边缘情况是否合理？（例如，技术用户或非技术用户编辑系统应用程序的数据库）。
只有当你处理这种情况与其他异常不同时才重要。除了错误消息不同之外。如果未启动，您会为他们启动汽车吗？或者你只是告诉他们？当然你应该处理边缘情况——它们会发生。

【解决方案4】：

大多数时候，我会推荐一个已经存在的异常。就像@Anthony 所说的ArgumentException。如果需要，您可以随时在 Exception 中留言。

有时，自定义异常会很方便。例如当你有这样的代码时：

catch(ArgumentException e)
{
    if(e.Message.Equals("The argument was bigger than 0"))
        // do something
    else
        // do something else
}

这会导致代码混乱，也许自定义事件或包装异常会更合适。

也许你也可以看看这个博客：http://blogs.msdn.com/b/jaredpar/archive/2008/10/20/custom-exceptions-when-should-you-create-them.aspx

【讨论】：

【解决方案5】：

听起来您正在尝试创建复制现有异常功能的异常。例如，你的空篮子场景可以由throw new ArgumentException("Basket not instantiated");处理

如有疑问，请返回 MSDN 上的 Exception Design Guidelines。

【讨论】：