谁的错？
异常设计背后的基本理论始于这样一个问题，“谁的错？”为了方便本文的讨论，这个问题的答案将总是以下三者之一：
库
应用程序
环境
当我们说“库”有问题，我们是指当前执行的某个方法有内部缺陷。在这种情况下，“应用程序”是调用库方法的代码（这有点混杂难分，因为库和应用程序代码可能在相同的程序集中。）最后，“环境”是指应用程序之外一切无法控制的东西。
库缺陷
最典型的库缺陷是nullreferenceexception。对库而言，它没有任何理由抛出可以被应用程序检测到的空引用异常。如果遇到了空，则库代码应该总是抛出一个更具体的异常，说明什么为空以及如何纠正这个问题。对于参数而言，这显然是一个argumentnullexception异常。而如果属性或字段为空，则invalidoperationexception通常更合适。
根据定义，任何表明库缺陷的异常都是该库中需要修复的bug。那并不是说应用程序代码没有bug，而是说库的bug需要首先修复。只有那样，才能让应用程序开发人员知道他也犯了错误。
这样做的原因是，可能有许多人使用同样的库。如果一个人在不应该传入空的地方错误地传入了空，则其他人想必也会犯同样的错误。把nullreferenceexception替换为一个可以清晰地显示出什么出错的异常，应用程序开发人员立即就可以知道什么出错了。
“成功之核（the pit of success）”
如果你读过有关.net设计模式的早期文献，那么你会经常碰到短语“成功之核”。其基本思想是这样的：让代码容易被正确使用，不容易被误用，并确保异常可以告诉你哪里出错了。遵循这个api设计理念，几乎可以保证开发人员一开始就编写出正确的代码。
这就是为什么一个没有注释的nullreferenceexception是如此糟糕。除了堆栈跟踪外（可能非常深入库代码），没有任何信息可以帮助开发人员确定他们哪里做错了。另一方面，argumentnullexception和invalidoperationexception则为库作者提供了一种方法，让他们可以向应用程序开发人员说明如何修复问题。
其他库缺陷
下一个库缺陷是arithmeticexception系列，包括dividebyzeroexception、finitenumberexception和overflowexception。再次，这总是意味着库方法的内部缺陷，即使那个缺陷只是一个缺失的参数有效性检查。
库缺陷的另外一个例子是indexoutofrangeexception。从语义上讲，它和argumentoutofrangeexception没什么不同，参见ilist.item，但它只适用于数组索引器。由于应用程序代码通常不会使用裸数组，所以这意味着，自定义的集合类会有bug。
自.net 2.0引入泛型列表以来，arraytypemismatchexception就很少见了。触发该异常的情况相当怪异。根据文档：
当系统无法将数组元素转换成声明的数组类型时会抛出arraytypemismatchexception。例如，一个string类型的元素无法存入一个int32数组，因为这两种类型之间无法转换。应用程序一般是不需要抛出这类异常的。
要做到这一点，前面提到的int32数组必须存入一个object[]类型的变量。如果你使用了原始数组，则库需要对此进行检查。由于这个原因及其他许多方面的考虑，最好是不要使用原始数组，而是将它们封装到一个合适的集合类中。
通常，其他转换问题是通过invalidcastexception异常反映出来的。回到我们的主题，类型检查应该意味着永远不会抛出invalidcastexception异常，而是向调用者抛出argumentexception或invalidoperationexception异常。
memberaccessexception是一个基类，涵盖了各种基于反射的错误。除了直接使用反射外，com互操作和动态关键词的不正确使用都会触发该异常。
应用程序缺陷
典型的应用程序缺陷是argumentexception及其子类argumentnullexception和argumentoutofrangeexception。以下是其他你可能不知道的子类：
system.componentmodel.invalidasynchronousstateexception
system.componentmodel.invalidenumargumentexception
system.duplicatewaitobjectexception
system.globalization.culturenotfoundexception
system.io.log.reservationnotfoundexception
system.text.decoderfallbackexception
system.text.encoderfallbackexception
所有这些都明确地表明应用程序有错误，而问题就出在调用库方法的行里。那条语句的两个部分都很重要。考虑下面的代码：
foo.customer = null; foo.save();
如果上述代码抛出了一个argumentnullexception异常，那么应用程序开发人员会很困惑。它应该抛出一个invalidoperationexception异常，说明当前行之前有什么地方出了问题。
以异常为文档
典型的程序员不阅读文档，至少不会首先阅读文档。相反，他或她会阅读公共api，编写一些代码并运行。如果代码不能正常运行，就到stack overflow上搜索异常信息。如果该程序员够幸运，则很容易在那里找到答案以及指向正确文档的链接。但即使如此，程序员们很可能也不会真正地读它。
那么，作为库作者，我们如何解决这个问题？第一步是直接将部分文档复制到异常中。
更多对象状态异常
invalidoperationexception有一个众所周知的子类objectdisposedexception。它的用途显而易见，然而，很少有可销毁类会忘记抛出这个异常。如果忘记了，则常见的结果是抛出nullreferenceexception异常。该异常是由dispose方法将可销毁子对象置为空所导致的。
与invalidoperationexception密切相关的是notsupportedexception异常。这两种异常很容易区分：invalidoperationexception是指“你现在不能那样操作”，而notsupportedexception是指“你永远不能对这个类做那种操作”。理论上讲，notsupportedexception应该只在使用抽象接口时出现。
例如，一个不可变集合在遇到ilist.add方法时应该抛出notsupportedexception异常。相比之下，一个可冻结集合在冻结状态下遇到该方法时会抛出invalidoperationexception异常。
notsupportedexception一个越来越重要的子类是platformnotsupportedexception。该异常表示，操作可以在某些运行环境里进行，但不能在其他环境里进行。例如，当将代码从.net移植到uwp或.net core时，你可能需要使用这个异常，因为它们没有提供.net framework的所有特性。
难以捉摸的formatexception
微软在设计.net的第一个版本时犯了一些错误。例如，从逻辑上讲，formatexception是一个参数异常类型，甚至文档也说“该异常是在参数格式无效时抛出”。但是，不管出于什么原因，它实际上没有继承argumentexception。它也没有地方存放参数名称。
我们暂时提供的建议是不要抛出formatexception异常，而是自己创建argumentexception的子类，可以命名为“argumentformatexception”或其他效果类似的名称。这可以为你提供必要的信息，如参数名称和实际使用的值，减少调试时间。
这把我们带回了最初的主题“异常设计”。是的，当你自行开发的解析器检测到了问题，你可以只抛出一个formatexception异常，但那无法为想要使用你的库的应用程序开发人员提供帮助。
有关这个框架设计缺陷，另外一个例子是indexoutofrangeexception。从语义上讲，它和argumentoutofrangeexception没什么不同，然而，这个特例只是针对数组索引器吗？不，那样想就错了。看下ilist.item的实例集，该方法只会抛出argumentoutofrangeexception异常。
环境缺陷
环境缺陷源于世界并不完美这样一个事实，诸如数据宕机、web服务器无响应、文件丢失等场景。当bug报告中出现环境缺陷时，需要考虑以下两个方面：
应用程序正确地处理了缺陷吗？
在这个环境里，是什么导致了缺陷？
通常，这会涉及人员分工。首先，应用程序开发人员应该第一个查找问题的答案。这不仅仅是说要处理错误并恢复，而且要生成一个有用的日志。
你可能想知道，为什么要从应用程序开发人员开始。应用程序开发人员要对运维团队负责。如果一次web服务器调用失败，则应用程序开发人员不能只是甩手大叫“不是我的问题”。他或她首先需要确保异常提供了足够的细节信息，让运维人员可以开展他们的工作。如果异常仅仅提供了“服务器连接超时”的信息，那么他们怎么能知道涉及了哪台服务器？
专用异常
notimplementedexception
notimplementedexception表示且仅表示一件事：这项特性还在开发过程中。因此，notimplementedexception提供的信息应该总是包含一个任务跟踪软件的引用。例如：
throw new notimplementedexception("参见工单#42.");
你可以提供更详细的信息，但实际上，你记录的任何信息几乎立刻就会过期。因此，最好是只将读者导向工单，他们可以在那里看到诸如该特性按计划将会在何时实现这样的信息。
aggregateexception
aggregateexception是必要之恶，但很难使用。它本身不包含任何有价值的信息，所有的细节信息都隐藏在它的innerexceptions集合中。
由于aggregateexception通常只包含一个项，所以在库中将它解封装并返回真正的异常似乎是合乎逻辑的。一般来说，你不能在没有销毁原始堆栈跟踪的情况下再次抛出一个内部异常，但从.net 4.5开始，该框架提供了使用exceptiondispatchinfo的方法。
解封装aggregateexception
catch (aggregateexception ex) { if (ex.innerexceptions.count == 1) //解封装 exceptiondispatchinfo.capture(ex.innerexceptions[0]).throw(); else throw; //我们真的需要aggregateexception }
无法回答的情况
有一些异常无法简单地纳入这个主题。例如，accessviolationexception表示读取非托管内存时有问题。对，那可能是由原生库代码所导致的，也可能是由应用程序错误地使用了同样的代码库所导致的。只有通过研究才能揭示这个bug的本质。
如果可能，你就应该在设计时避免无法回答的异常。在某些情况下，visual studio的静态代码分析器甚至可以分析该规则所涵盖的标识冲突。
例如，applicationexception实际上已经废弃。framework设计指南明确指出，“不要抛出或继承applicationexception。”为此，应用程序不必抛出applicationexception异常。虽说初衷如此，但看下下面这些子类：
microsoft.jscript.breakoutoffinally
microsoft.jscript.continueoutoffinally
microsoft.jscript.jscriptexception
microsoft.jscript.nocontextexception
microsoft.jscript.returnoutoffinally
system.reflection.invalidfiltercriteriaexception
system.reflection.targetexception
system.reflection.targetinvocationexception
system.reflection.targetparametercountexception
system.threading.waithandlecannotbeopenedexception
显然，这些子类中有一些应该是参数异常，而其他的则表示环境问题。它们全都不是“应用程序异常”，因为他们只会被.net framework的库抛出。
同样的道理，开发人员不应该直接使用systemexception。同applicationexception一样，systemexception的子类也是各不相同，包括argumentexception、nullreferenceexception和accessviolationexception。微软甚至建议忘掉systemexception的存在，而只使用其子类。
无法回答的情况有一个子类别，就是基础设施异常。我们已经看过accessviolationexception，以下是其他的基础设施异常：
cannotunloadappdomainexception
badimageformatexception
datamisalignedexception
typeloadexception
typeunloadedexception
这些异常通常很难诊断，可能会揭示出库或调用它的代码中存在的难以理解的bug。因此，和applicationexception不同，把它们归为无法回答的情况是合理的。
实践：重新设计sqlexception
请记住这些原则，让我们看下sqlexception。除了网络错误（你根本无法到达服务器）外，在sql server的master.dbo.sysmessages表中有超过11000个不同的错误代码。因此，虽然该异常包含了你需要的所有底层信息，但是，除了简单地捕获&记录外，你实际上难以做任何事。
如果我们要重新设计sqlexception，那么我们会希望，根据我们期望用户或开发人员做什么，将其分解成多个不同的类别。
sqlclient.networkexception会表示所有说明数据库服务器本身之外的环境存在问题的错误代码。
sqlclient.internalexception会包含说明服务器存在严重故障（如数据库损坏或无法访问硬盘）的错误代码。
sqlclient.syntaxexception相当于我们的argumentexception。它是指你向服务器传递了糟糕的sql（直接或者因为orm的bug）。
sqlclient.missingobjectexception会在语法正确但数据库对象（表、视图、存储过程等）不存在时出现。
sqlclient.deadlockexception出现在两个或多个进程试图修改相同的信息产生冲突时。
这些异常中的每一种都隐含着一个行动方案。
sqlclient.networkexception：重试操作。如果频繁出现，则请联系运维人员。
sqlclient.internalexception：立即联系dba。
sqlclient.syntaxexception：通知应用程序或数据库开发人员。
sqlclient.missingobjectexception：请运维人员检查上一次数据库部署是否丢了东西。
sqlclient.deadlockexception：重试操作。如果频繁发生，则查找设计错误。
如果要在实际的工作中这样做，那么我们必须将所有11000多个sql server错误代码映射到那些类别中的一个，这是一项特别令人望而生畏的工作，这也就解释了为什么sqlexception是现在这个样子。
总结
当设计api时，为了便于纠正问题，要将异常根据需要执行的动作的类型进行组织。这样更容易编写出自校代码，记录更准确的的日志，更快地将问题传达给合适的人或团队。
关于作者
jonathan allen在90年代末开始参与面向医务室的mis项目，把它们从access和excel逐步提升为一种企业级的解决方案。他花了五年时间编写金融行业自动交易系统，然后决定转向高端用户界面开发。在业余时间里，他喜欢学习15到17世纪之间的西方格斗技巧，并进行相关写作。
以上就是.net异常设计原则的内容。