我们在大多数事件处理程序中都有异常捕获代码等，这会导致非常复杂的逻辑，并设置标志以表明是否存在异常，以便不执行下一步等。
乍一看，我会将所有异常报告/日志记录移动到AppDomain.UnhandledException事件，但是根据我对WinForms的经验，这将导致很多异常丢失。
此外，如果存在异常，我们还会在日志消息中包含用户尝试执行的操作的详细信息。
那么在WCF应用程序中的异常日志记录/报告/恢复中，错误和良好的人体验是什么？
（我想说我们有类似于模型 - 视图ViewModel（MVVM）模式的东西）正在使用中，但我们不能并且距离能够使用任何“干净”设计还有很长的路要走）
答案 0 :(得分：1)
它不是特定于WPF，但处理异常的最佳位置是在用户与表单的交互转换为逻辑进程时处理它们。这可以是代码隐藏或控制器方法。
只有在这个级别，您才知道用户尝试做什么以及遇到异常情况时采取的合理步骤。
当然，如果您不知道可能抛出的异常，请不要尝试处理它们。并且不要费心处理您无法做任何事情的异常。
答案 1 :(得分：0)
你永远不应该使用标志来说明已经处理了异常 - 闻起来像是糟糕的设计。
例外情况分为两类：
您的预期应该很快处理，并根据异常类型进行记录。例如，如果用户输入了一些被业务层中的验证代码拒绝的数据，我会捕获异常并通知用户，但不记录它 - 因为它是预期的，我可以处理它。其他人可能是“预期的”，但您无法处理它 - 就像WCF呼叫因超时或超大数据包而失败。你应该明确地记录 - 你甚至可以从中恢复，所以再一次它应该被抓住并处理。注意缺少标志 - 要么处理异常，要么继续冒泡。如果你需要采取行动，你可以这样做，然后重新抛出异常，让它进一步冒泡 - 看，仍然没有标志：）
我在过去在ASP.NET应用程序中抛出（自定义）预期异常时采用的另一种方法是将其标记为能够在本地处理。这意味着当aspx捕获到错误（所有apsx继承自的基页中的通用错误处理程序）时，它知道它是否应该在页面内本地显示它（在资源文件中进行文本查找之后），或者是否应该重定向到错误页面。当混合使用标准回发和ajax回调时，这种方法特别有用（尽管对WPF应用程序可能不是特别有用）。
对于重大意外错误，您可以在应用程序级别here is a previous SO post about it捕获这些错误。另外两篇可能有用的相关帖子here和here。
我应该提到的另一件事是确保你的错误记录是相对防弹的 - 没有什么比你的异常日志记录过程抛出异常更糟糕了，并且丢失了你试图追踪的那个棘手错误的所有有价值的细节愤怒的用户。