在WPF应用程序中全局捕获异常？ [英] Globally catch exceptions in a WPF application?

问题描述

我们正在使用一个WPF应用程序，其中的一部分可能会在运行时抛出异常。我想全局捕获任何未处理的异常并记录它们，但是否则继续程序执行，就好像没有发生任何事情（有点像VB的 On Error Resume Next ）。

这是否可能在C＃中？如果是这样，我需要在何处放置异常处理代码？

目前我看不到任何一个可以包含尝试 / catch ，并捕获可能发生的所有异常。即使这样，我也会离开任何已经被处死的东西。或者我在这里有错误的路线吗？

ETA：因为下面很多人指出：应用程序不是用于控制核电植物。如果它崩溃了，这并不是很大的事情，但是与UI相关的随机异常在使用它的上下文中是一个麻烦。有些（可能还有）其中的一些，因为它使用插件架构，并可能被其他人扩展（也就是学生在这种情况下;所以没有经验的开发人员能够完全写错误对于被捕获的异常：我将它们记录到一个日志文件中，包括完整的堆栈跟踪。那是演习的整体。只是为了对付那些正式对VB的OERN进行类比的人。

我知道盲目忽略某些类错误是危险的，可能会损坏我的应用程序实例。如前所述，这个程序对任何人来说都不是关键任务。没有一个人在正确的心中会打赌人类文明的生存。这只是测试某些设计方法wrt的一个小工具。软件工程。

为了立即使用应用程序，在异常情况下不会发生很多事情：

• 没有异常处理 - 错误对话框和应用程序退出。实验必须重复，尽管可能与另一个主题。没有记录错误，这是不幸的。


• 通用异常处理 - 良性错误被捕获，没有损害。这应该是我们在开发过程中看到的所有错误的常见情况。忽略这种错误应该没有立即的后果;核心数据结构测试足够好，可以轻松地存活下来。


• 通用异常处理 - 严重错误被捕获，可能会在以后崩溃。这可能很少发生。我们从来没有见过它。该错误记录无论如何，崩溃可能是不可避免的。所以这在概念上类似于第一种情况。除了我们有一个堆栈跟踪。在大多数情况下，用户甚至不会注意到。

对于程序生成的实验数据：严重错误在最坏的情况下，只会导致无法记录数据。微妙的改变实验结果稍微有点不太可能。即使在这种情况下，如果结果似乎可疑，则记录错误;如果总数是一个异常值，那么数据点仍然可以丢掉。

总结一下：是的，我认为自己至少还是有一定的理智，异常处理程序使程序运行必然完全是邪恶的。如前所述，这样的决定可能是有效的，具体取决于应用程序。在这种情况下，它被判定为有效的决定，而不是全部和完全的胡说。 对于任何其他应用程序，决定可能会有所不同。。但是请不要指责我或其他那些在该项目中工作的人因为无视错误而潜在地炸毁世界。

旁注：该应用程序只有一个用户。这不是像Windows或Office那样被数百万用户使用的用户，所有这些用户的成本将会在第一时间有所不同。

解决方案

使用 Application.DispatcherUnhandledException Event 。有关摘要，请参阅此问题（请参阅 Drew Noakes'answer ）。

请注意，仍然会有异常，妨碍您成功恢复应用程序如堆栈溢出，耗尽的内存，或者在尝试保存到数据库时丢失网络连接。

We are having a WPF application where parts of it may throw exceptions at runtime. I'd like to globally catch any unhandled exception and log them, but otherwise continue program execution as if nothing happened (kinda like VB's On Error Resume Next).

Is this possible in C#? And if so, where exactly would I need to put the exception handling code?

Currently I can't see any single point where I could wrap a try/catch around and which would catch all exceptions that could occur. And even then I would have left whatever has been executed because of the catch. Or am I thinking in horribly wrong directions here?

ETA: Because many people below pointed it out: The application is not for controlling nuclear power plants. If it crashes it's not that much a big deal but random exceptions that are mostly UI-related are a nuisance in the context where it would be used. There were (and probably still are) a few of those and since it uses a plugin architecture and may be extended by others (also students in that case; so no experienced developers that are able to write completely error-free code).

As for the exceptions that get caught: I do log them to a log file, including the complete stack trace. That was the whole point of that exercise. Just to counter those people that were taking my analogy to VB's OERN too literally.

I know that blindly ignoring certain classes of errors is dangerous and might corrupt my application instance. As said before, this program isn't mission-critical for anyone. No-one in their right mind would bet the survival of the human civilization on it. It's simply a little tool for testing certain design approaches wrt. software engineering.

For the immediate use of the application there are not many things that can happen on an exception:

• No exception handling – error dialog and application exit. Experiment has to be repeated, though likely with another subject. No errors have been logged, which is unfortunate.
• Generic exception handling – benign error trapped, no harm done. This should be the common case judged from all errors we were seeing during development. Ignoring this kind of errors should have no immediate consequences; the core data structures are tested well enough that they will easily survive this.
• Generic exception handling – serious error trapped, possibly crash at a later point. This may happen rarely. We've never seen it so far. The error is logged anyway and a crash might be inevitable. So this is conceptually similar to the very first case. Except that we have a stack trace. And in the majority of cases the user won't even notice.

As for the experiment data generated by the program: A serious error would at worst just cause no data to be recorded. Subtle changes that change the result of the experiment ever so slightly are pretty unlikely. And even in that case, if the results seem dubious the error was logged; one can still throw away that data point if it's a total outlier.

To summarize: Yes, I consider myself still at least partially sane and I don't consider a global exception handling routine which leaves the program running to be necessarily totally evil. As said twice before, such a decision might be valid, depending on the application. In this case it was judged a valid decision and not total and utter bullshit. For any other application that decision might look different. But please don't accuse me or the other people who worked on that project to potentially blow up the world just because we're ignoring errors.

Side note: There is exactly one user for that application. It's not something like Windows or Office that gets used by millions where the cost of having exceptions bubble to the user at all would be very different in the first place already.

解决方案

Use the Application.DispatcherUnhandledException Event. See this question for a summary (see Drew Noakes' answer).

Be aware that there'll be still exceptions which preclude a successful resuming of your application, like after a stack overflow, exhausted memory, or lost network connectivity while you're trying to save to the database.

这篇关于在WPF应用程序中全局捕获异常？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！