在WPF应用程序中，应该在哪里捕获和处理异常？

我们在大多数事件处理程序中都有异常捕获代码等，这导致了非常复杂的逻辑，并设置了标志来说明是否存在异常，以便不执行下一步等

乍一看，我会将所有异常报告/日志记录移动到AppDomain.UnhandledException事件，但是根据我使用WinForms的经验，这将导致许多异常丢失

此外，当出现异常时，我们会在日志消息中包含用户尝试执行的操作的详细信息

那么，在WCF应用程序中，人们在异常记录/报告/恢复方面的体验是什么呢

---

（我想说的是，我们使用了类似模型-视图-模型（MVVM）模式的东西，但我们没有，而且距离使用任何“干净”的设计还有很长的路要走）

它不是WPF特有的，但处理异常的最佳位置是在用户与表单的交互转换为逻辑过程时处理异常。这要么在codebehind中，要么在控制器方法中

只有在这个级别上，您才知道用户正在尝试做什么，以及在遇到异常情况时应该采取什么合理的步骤

---

当然，如果您不知道可能抛出哪些异常，请不要尝试处理它们。不要费心处理你无能为力的异常。

你不应该用标志来表示异常已被处理——这听起来像是糟糕的设计

例外情况分为两类：

• 预期（例如验证失败，数据无法放入数据库）
• 意料之外

您预期的异常应该很快得到处理，并根据异常的类型进行记录。例如，如果用户在业务层输入了一些被验证代码拒绝的数据，我会捕获异常并通知用户，但不会记录它——因为这是预期的，我可以处理它。其他的可能是“预期的”，但您无法处理它——比如WCF调用由于超时或数据包过大而失败。这一点你应该明确地记录下来——你甚至可以从中恢复过来，所以再次应该捕获并处理它。请注意缺少标志-异常要么被处理，要么继续冒泡。如果你需要采取行动，你可以这样做，然后重新抛出异常，让它进一步冒泡-看，仍然没有标志：）

我过去在ASP.NET应用程序中抛出（自定义）预期异常时采用的另一种方法是将其标记为能够在本地处理或不能在本地处理。这意味着，当aspx捕获到错误（所有APPX继承自的基本页中的通用错误处理程序）时，它知道是否应该在页面中本地显示它（在资源文件中执行文本查找之后），或者是否应该重定向到错误页。当混合使用标准回发和ajax回调时，这种方法特别有用（但对WPF应用程序可能不是特别有用）

对于重大意外错误，您可以在应用程序级别捕获这些错误。另外两篇可能有用的相关文章，以及

---

我要提到的另一件事是确保您的错误日志记录相对来说是防弹的——没有什么比您的异常日志记录过程抛出一个异常，并丢失您正试图为那个愤怒的用户追踪的那个棘手错误的所有有价值的细节更糟糕的了。

我正在努力解决这个问题“隐藏问题并继续，这样客户就不会抱怨挤压”问题。考虑到客户希望即使在所有系统都不工作的情况下也能使用部分系统，这不是一个不合理的要求。@ian使用“即使在所有系统都不工作的情况下也能使用部分系统”“这是一个很好的办法，最终导致系统腐败。如果你能处理一个异常，那太棒了。处理它。如果你不知道，与其以未知状态结束，不如快速失败。你的客户想要的并不一定是他们真正需要的。作为一名开发人员，最困难的部分是有时告诉你的客户“不”。威尔是对的。我想让客户知道系统何时出现故障。但要传达一个友好的信息。“发生意外错误-7879897979。请与帮助台联系。”该号码可能是“登录”时生成的例外ID。对我们来说追踪这个问题会很容易。也许这个问题的答案在这里也有帮助？