4

感谢您对这个问题的输入，我决定让我的 Create() 方法抛出异常，所以正如 Jon Skeet 所说，你不必到处处理它们，可以让它们冒泡，似乎是最好的方法对于更大的应用程序。

所以现在我用这段代码创建我的类的实例：

try
{
    SmartForms smartForms = SmartForms.Create("ball");
    smartForms.Show();
}
catch (CannotInstantiateException ex)
{
    Console.WriteLine("Item could not be instantiated: {0}", ex.Message);
}

自定义异常：

using System;

namespace TestFactory234.Exceptions
{
    class CannotInstantiateException : Exception
    {

    }
}

我怎么知道要使用哪个 Exception 类？

在上面的例子中，我创建了自己的异常，因为我不知道从哪里获得“所有系统异常”的列表，或者是否有一个“无法实例化对象”或者它是否有其他含义使用它等等。对我来说，选择一个异常类型似乎是一个随意的过程，所以创建我自己的似乎是最好的主意。

还是我错过了一些关于异常的东西？决定使用哪种异常类型涉及哪些其他含义？

4

6 回答 6

5

如果您无法创建对象的原因是因为 Create 的参数无效，您可能应该抛出一个ArgumentException. ArgumentException但是，如果您真的希望能够将这种异常单独处理给其他人，您总是可以创建我们自己的派生类。（你确定你要？）

于 2009-06-10T13:58:50.690 回答
3

为什么要创建自定义例外？非常详细地解释了为什么以及何时使用自定义异常。

于 2009-06-10T14:00:19.033 回答
2

当能够捕获并知道发生的特定异常情况可能有用时，创建一个新类型。知道找不到文件而不是通用 IO 异常是否有用？

于 2009-06-10T13:57:36.043 回答
2

写了一篇关于这个主题的完整博客文章，您可能会觉得有趣

总而言之，不要编写自定义异常类，除非您确实希望有人同时捕获并处理该类型。

于 2009-06-10T14:02:02.040 回答
0

我认为查找现有异常的好地方是在帮助文件中……如果您查找Exception该类的帮助，则在概述页面上应该有一个派生类列表。

如何决定是创建一个新的（派生自Exception），还是从现有的继承，取决于异常的含义。

正如 Jon 所说，如果您的代码对Create方法的参数进行了一些验证，您可能希望生成一个异常派生自ArgumentException（例如，ArgumentNonExistentEntityException如果指定的 ID 不存在，尽管这有点满嘴）。

如果您正在创建的异常在概念上并未从已经存在的异常中“继承”其含义，那么只需为您的库无耻地创建一个新异常即可。

于 2009-06-10T14:03:38.450 回答
0

您将创建一个自定义异常类型来为错误提供更多上下文信息或含义，否则您将依赖运行时生成的异常类型。例如，像 System.DivideByZero 这样的异常在应用程序的顶部冒泡时可能并不明显。相反，除了上述“除零”错误之外，您还可以创建自定义异常以提供更多上下文信息。

有关不同运行时生成的异常的参考，请查看 MSDN 的系统命名空间。这不是一个详尽的列表，因为异常可以由本机代码生成，也可以由第三方库生成。

于 2009-06-10T14:14:09.223 回答