c# - 接口(interface)实现应该如何处理调用者可能期望的类型的意外内部异常？

Question

如果一个类实现了一个接口(interface)，它应该如何处理以下情况:

1. 在执行方法或属性时，发生了调用者可能会遇到的类型的内部错误合理地期望处理，但调用者可能不应该处理。例如，IDictionary.Add 在内部执行某些操作，在暗示字典已损坏但不会暗示系统其余部分有任何问题的情况下会产生 ArgumentException？或者他们暗示某些东西在字典之外被破坏了？调用者可能期望捕捉并处理字典中存在重复键的事实，因为在某些情况下异常可能令人烦恼(例如，相同的代码可能用于其他线程未访问的字典和 ConcurrentDictionary也就是说，如果尝试添加重复记录导致完全失败，语义将是可行的)。让 ArgumentException 渗入会导致调用者认为字典处于相同状态，就好像添加从未发生过一样，这可能很危险，但抛出其他一些异常类型似乎会造成混淆。
2. 在方法或属性的执行过程中，发生调用者可能应该或不应该处理的异常，并且接口(interface)的定义没有提供任何与远程相关的异常的提示可能发生。例如，假设在 IEnumerator 的评估中出现问题，或者暗示(1)枚举器被破坏(可能是由于另一个线程上的意外操作)但重试枚举可能会成功； (2) 可枚举对象本身可能已损坏或无法使用，但系统中的其他一切可能都没有问题(例如，延迟评估的文件解析例程命中无效记录)； (3) 可枚举对象之外的东西已经损坏。 IEnumerable 只有一个可以抛出的已定义异常，但调用者可能希望根据异常的“严重性”改变其操作。

如果我有我的想法，系统会定义一些类型，如 RetryableFailureException、CleanFailureException、ObjectCorruptFailureException，并且大多数接口(interface)将被允许抛出这些类型或它们的派生类型。既然不是这样，那么应该如何正确处理接口(interface)，无论是从接口(interface)的角度还是从调用者的角度？

顺便说一句，有一种模式我还没有看到实现，但看起来很有用，它是让方法接受委托(delegate)参数来执行，以防方法失败导致“try”方法返回 false .这样一个由调用者提供的委托(delegate)不仅可以抛出接收者知道要查找的异常，而且还可以设置一个标志，否则只能由调用者使用。调用者因此可以知道被捕获的异常确实是预期的异常。

Answer 1

接口(interface)的工作是定义类必须具有的成员(及其签名)，而不是定义它们的实现方式。因此我会说让异常在堆栈中冒泡。如果您真的想定义契约并控制一些实现(例如错误处理)，那么您应该使用基类调用的 MustOverride 方法创建一个基类(在这种情况下我会倾向于 MustInherit/Abstract 类)它的方法(在你的情况下，在 Try Catch 中，这样你就可以进行特殊的错误处理)。