我们的应用程序是模块化的（模块组做特定的事情）。这些模块具有事件处理程序。这些事件可以从其他模块或应用程序菜单中触发。从C＃模块抛出的异常
情况：
模块A（具有UI）临危事件 “deleteitem”。事件参数应该包含要删除的项目名称。但在这种情况下，它是空的。某个地方，有人与某事混淆了。
问题（S）：
如果该模块扔？记住，该模块将被扔进一个事件处理程序，并可能导致应用程序崩溃，因为模块编写者不知道是否处理了该异常。
上面的场景是关于从模块引发的可能导致应用程序崩溃的更大问题的更大问题的快照。反对它的论点是应用程序可以在没有特定模块的情况下继续工作。那么，谁应该确保 - 模块或应用程序？
如果该项目的名称是什么，预期总是存在的，它是null是一个特殊的情况下，这绝不应该发生，你应该抛出的，现在你的应用是在不应该发生
如果这是调用者可以从中恢复的东西，他们将编写自己的异常处理例程来处理它。
这是一件重要的事件吗？你能忽略它吗？我会认为这是一个空洞的事件，而忽略它。我想不能删除的东西不是关键任务。好主意是将这些信息记录为警告或错误，所以你知道它发生了。
我的规则是，如果某件事可以重新发布，它不是必需的，但如果它不能 - 这很重要。但是这可以根据特定的应用上下文而改变。
不好的事情发生，如果你可以，你应该尝试从他们身上恢复。我的首要任务是确保应用程序（模块）即使被馈送错误的数据也不会崩溃，但一定要确保您知道发生了不好的事情（日志记录）。如果你无助而且无法做其他事情，例外是最后的手段。
我在这里描述的最适用于分离的模块，例如WCF服务。如果它全部在一个应用程序中（模块是类），最好的办法可能是返回一个异常，但确保调用者可以处理它。所以模块分离在这里很重要 - 分离越多，错误恢复能力就越强。 WCF服务或Windows服务不应该崩溃。
这正是我的同事们的丰碑。那么，可以放弃应用程序的错误状态，询问你的模块做什么吗？ – Jimmy 2012-04-02 10:54:09
刚刚添加到我的答案。不好的事情发生，如果你能，你应该从他们身上恢复。如果你无助而且无法做其他事情，例外是最后的手段。 – 2012-04-02 10:57:54
我强烈建议不要忽略错误。 Oded在他的回答中提到，应用程序现在处于未知状态。您无法控制进一步执行的结果。如果你幸运的话，你会得到另一个例外，这将是很难知道的根本原因。如果你不那么幸运，最终会得到损坏的用户数据。 – 2012-04-02 11:01:42
做扔。通过修复抛出格式错误的事件的模块，一旦发现它们，就立即响应任何此类异常。
答案部分取决于你如何建立和版本的产品（即触发事件的模块是否与所有的听众保持和建在一起）。
由于您描述的是一种非常极端的行为，表明产品缺陷，所以尽早找到它是件好事。如果您没有更好的方法来提醒正在使用或测试有缺陷的软件的任何人，请投掷。另一方面，不要抛出较不极端的情况，比如事件可能很好地形成，或者当你自己的模块可能对它负责时。
如果发现相对较早，产品缺陷最便宜;但过度投掷可能会导致缺陷传播到不相关的模块（即将收到一些但不是所有相关事件），从而延迟锁定缺陷。
我觉得一样。我在模块中发现了一个事件，这个事件要求我做一些我不能做的事情，这些事情清楚地表明应用程序中某处出现了错误。我认为最好早点知道这一点，而不是继续使用不稳定的应用程序。 – Jimmy 2012-04-02 11:03:47
如果它没有扔掉还会发生什么，你想要吗？ – Jodrell 2012-04-02 10:48:14
如果它不扔，应用程序将继续。我想要那个吗？这就是问题。我不想要，因为我知道有什么地方出了问题。反参数让应用程序继续执行，因为应用程序可以在模块不执行操作的情况下继续。 – Jimmy 2012-04-02 10:56:45