当尝试在运行时定位类型(通常是类)时，如果名称传递给

  Type.GetType(string typeName, bool throwOnError = True) 

无法定位重载，引发的异常是TypeLoadException。

我理解这背后的想法是 CLR 认为问题在于我们(还)没有加载包含所寻求类型的(或任何)程序集，但我的想法是问题是 CLR 无法找到给定名称的类。 (当然，名字可能拼错了。)

如果我想告诉我的面向反射的运行时定义代码工具的客户他们要求的类没有找到，我似乎有两个选择——要么用 TypeLoadException 告诉他们，要么定义我自己的 ClassNotFoundException。

我找到了 this link它提供了(显然很好而且肯定是完整的)关于创建自定义异常类(在 C# 中)的信息，但是要(正确实现)这样一个简单的想法需要做大量的工作。

看来我还想构建一些知道我认为我的客户可能想要使用的公共(public)类(或其 namespace )的程序集名称的东西，以便我可以在我的用户/当我的用户时加载正确的程序集要求一个在有点知名但尚未加载的程序集中的类。这似乎也是 BCL 很可能为我们提供的一项费用。 (我想这就是 AppDomain.TypeResolve 事件的用途，但我将提出一个单独的问题，以尝试找到该概念的易于重用和可扩展的实现。)

与此同时，我会再问一次——为什么 ClassNotFoundException 还没有定义？

请您参考如下方法:

如果您的自定义 TypeNotFoundException 提供的信息比 CLR 的 TypeLoadException 提供的信息多，那么我认为创建新的异常类型是完全可以接受的。

需要考虑的一件事是您是否需要使用已经 try catch CLR 的 TypeLoadException 的现有代码进行操作。如果是这样，那么该代码可能不再有效，因为您的异常不会被该代码捕获。

我只能猜测为什么 CLR 的异常是因为我没有编写该代码。异常不一定能够准确检测出找不到类型的原因。如您所述，一种可能性是类型名称拼写错误。其他原因可能是安全要求失败、无法从磁盘读取程序集文件、发现错误的程序集版本、公钥不匹配、程序集不在探测路径中、AppDomain 的类型解析器失败，或者任何其他原因。

由于失败的许多可能原因，异常非常通用，否则会有 20 种异常类型，我认为大多数人会同意太多。

关于异常要考虑的另一件事是:假设有人遇到异常 - 您希望他们接下来做什么？也就是说，您希望以何种有意义的方式以编程方式处理异常。如果异常仅适用于开发人员，那么真正重要的是异常消息而不是异常的类型。如果以编程方式处理异常，那么您将如何以不同方式处理这 20 种情况？或者它们甚至会有所不同？