从C#模块引发异常

我们的应用程序是模块化的（一组做特定事情的模块）。模块具有事件处理程序。这些事件可以从其他模块或应用程序菜单触发

情况：

模块A（具有UI）接收事件“deleteitem”。事件参数应包含要删除的项名称。但在这种情况下，它是空的。某个地方，有人搞砸了什么

问题：

模块是否应该抛出？请记住，模块将在事件处理程序中抛出，并可能使应用程序崩溃，因为模块编写器不知道是否处理了异常

---

上面的场景是一个更大问题的一个缩影，这个问题涉及从模块中抛出可能导致应用程序崩溃的例外。反对它的理由是，应用程序可以在没有特定模块的情况下继续工作。那么，谁应该确保——模块还是应用程序

这是一项基本活动吗？你能忽略它吗？我会将其视为一个空洞的事件而忽略它。我想不能删除某些内容不是关键任务。最好将此信息记录为警告或错误，以便您知道它发生了

我的规则是，如果某些东西可以重新发行，它就不是必要的，但如果不能，它就很重要。但这可能会根据特定的应用程序上下文而改变

坏事发生了，如果可以的话，你应该试着从中恢复过来。我的首要任务是确保应用程序（模块）不会崩溃，即使提供了错误的数据，但一定要确保您知道发生了不好的事情（日志记录）。例外是最后的手段，如果你无能为力，不能做任何其他事情

---

我在这里描述的内容最适用于单独的模块，例如WCF服务。若所有这些都在一个应用程序中（模块是类），最好是返回一个异常，但确保调用者能够处理它。因此，模块分离在这里很重要——分离越多，错误恢复能力就越强。WCF服务或Windows服务不应崩溃。

如果项目名称应始终存在，并且为

null

是一种例外情况，这种情况不应发生，您应该抛出，因为您的应用程序现在处于不应发生的未知状态

如果调用者可以从中恢复，他们将编写自己的异常处理例程来处理它。

Do throw。一旦发现异常，立即修复引发错误事件的模块，以应对任何此类异常

答案部分取决于您如何构建和版本化产品（触发事件的模块是否与所有侦听器一起维护和构建）

因为您描述的是一种非常极端的行为，表明产品存在缺陷，所以最好尽早发现它。如果您没有更好的方法提醒正在使用或测试有缺陷软件的任何人，请不要抛出

另一方面，不要在不太极端的情况下抛出，例如事件可能格式良好，或者您自己的模块可能对此负责

---

产品缺陷如果发现得比较早，修复成本最低；但是过度抛出可能会导致缺陷传播到不相关的模块（这些模块将接收一些但不是所有相关事件），从而延迟将缺陷锁定。

如果它不抛出还会发生什么，您希望这样吗？如果它不抛出，应用程序将继续。我想要吗？-这是个问题。我不想那样，因为我知道某处出了问题。相反的论点是让应用程序继续运行，因为应用程序可以在模块不执行操作的情况下继续运行。这也是我的想法。Maciej的回答是我面临的同事们的反驳。这里应该提出一个实际的例外，比如这一个。如果合适的话，可以记录异常并在堆栈的更上层忽略它。@Jodrell-如果试图访问传递的

null

参数的成员，将抛出异常。@Oded，true，我同意。我的意思是，不要捕捉和抑制异常，给调用方函数工作的印象。您可以记录和抑制以防止在顶部向用户显示一次@奥德。您如何看待将IApplicationErrorHandler接口注入模块？模块可以从接口调用Reporterror（类型）。通过这种方式，模块可以报告错误，但接口实现可以决定应用程序是否应该继续。这正是我的同事们的意见。那个么，放弃应用程序的错误状态并要求你们的模块做一些事情可以吗？只是在我的回答中添加了更多。坏事发生了，如果可以，你应该从中恢复过来。如果你无能为力，不能做任何其他事情，例外是最后的选择。我强烈建议你不要忽略这个错误。正如Oded在回答中提到的，应用程序现在处于未知状态。您无法控制进一步执行将导致什么结果。如果幸运的话，你最终会遇到另一个异常，这将很难知道问题的根本原因。如果你运气不好，最终会导致用户数据损坏。@MaciejDopieralski因此，如果我的应用程序可以继续运行，而没有任何人抱怨错误情况，而且将来还会有更多错误，那么随着时间的推移，应用程序将变得越来越不稳定。这样可以吗？同样，这取决于事件的重要性。无论哪种情况，都不要忽视它。确保通过日志了解问题。但在我看来，崩溃UI是最后的手段，如果发生了不可恢复的事情（如未配置或磁盘错误等），应该会发生崩溃。我也这么认为。我在模块中遇到了一个事件，它要求我做一些我不能做的事情，这清楚地表明了应用程序中的某个错误。我认为这是最好的