.net 不同的实现类抛出不同的异常类型可以吗？

如果我有一个接口，我在其中添加注释来标识将抛出的特定异常，那么实现类抛出不同的异常可以吗

一个（坏的）例子是：

public interface IWidgetWorker {
    /// <summary>
    /// Do the work required for the specified work id.
    /// </summary>
    /// <param name="workId">The id of the piece of work to do</param>
    /// <exception cref="ArgumentException">Thrown if workId is empty</exception>
    public void DoWork(Guid workId);
}

public class DatabaseWidgetWorker : IWidgetWorker {
    public void DoWork(Guid workId) { 
        // throw some database related exception
    }
}

public class WebWidgetWorker : IWidgetWorker {
    public void DoWork(Guid workId) {
        // throw some web related exception
    }
}

公共接口IWidgetWorker{ /// ///执行指定工作id所需的工作。 /// ///要执行的工作的id ///如果workId为空，则抛出 公共无效工作（Guid工作ID）； } 公共类数据库WidgetWorker:IWidgetWorker{ 公共无效工作（Guid工作ID）{ //抛出一些与数据库相关的异常 } } 公共类WebWidgetWorker:IWidgetWorker{ 公共无效工作（Guid工作ID）{ //抛出一些与web相关的异常 } }

---

也许我添加了一个

WidgetWorkerException

类？我在哪里记录实现类可能抛出的特定异常

实现类应该只抛出接口中指定的异常。如果界面没有提供任何报告错误的可能性，要么界面设计不好，要么实现者应该接受它，因为界面用户真的不在乎。

这可能是主观的。我的感觉是，实现类应该抛出当时自然抛出的任何异常。接口不声明哪些异常是允许的，哪些是不允许的。编译器不会查看您的注释，类可以抛出其他异常，并且仍然是接口的有效实现

如果出于某种原因，您需要将这些异常设置为单一类型，则可以捕获它们，并在调用IWidgetWorker.DoWork的任何位置使用原始的内部异常重新显示它们

workId为空的情况可以在调用进入实现之前处理，因此没有理由让不同的实现处理相同的ArgumentException检查和抛出

在其他编程环境中可能会有所不同。我认为可能的例外必须用某些语言声明，但不能在这里声明

---

接口的文档可以说明各种异常是如何解释的，以及消费代码将做什么。如果异常是这样或那样，可能消费代码会在一段时间间隔后重试，但在其他情况下会终止报告错误。

接口设计的一部分通常会记录预期的异常。这些异常在创建接口时是合乎逻辑的，例如调用方法且对象处于错误状态时的

invalidoOperationException

，或传递不正确参数时的

ArgumentOutOfRangeException

但是，接口可以通过多种方式实现。实现完全可以查看文件系统或对数据库的调用，从而引入一系列在定义接口时无法预见的异常

您希望知道方法引发特定异常的唯一原因是能够以不同于常规异常处理的方式处理该条件。当您通过接口进行调用时，您是针对接口而不是实现进行编码的。您无法知道实现是如何工作的，因此无法以任何特定方式处理异常。您必须退回到更一般的异常处理

---

经验法则应该是记录异常，这些异常在公开接口的情况下是合理的，但是您应该期望实现抛出超出这些异常的异常。健壮的代码将有一种机制来以通用方式处理这些未知异常。

由.net framework执行：

IDbCommand.ExecuteOnQuery

仅定义InvalidOperationException，而

SqlCommand.ExecuteOnQuery

也可以引发SqlException。