应用程序在处理 UnhandledException 后进入未知/锁定状态

发布于 2024-12-17 23:01:55 字数 959 浏览 2 评论 0原文

在我的 App.xaml.cs 中,我有事件来处理 DispatcherUnhandledExceptions (UI 线程)和 UnhandledException (非 UI 线程)。当我在dispatcher.Invoke内部抛出异常时,dispatcherhandler捕获异常并处理它。我在记录异常后将 e.Handled 设置为 true。现在奇怪的行为是,如果我将异常抛出到调度程序之外。作为常规语句调用,控制将发送到调度程序异常处理程序,但是在处理该方法之后,应用程序基本上失去了控制,但我可以通过查看来判断它仍在运行 在与另一件事中的停止按钮处

,如果我将 e.handled 设置为 false,则控制将发送到非 ui 线程异常处理程序。

那么让我困惑的是为什么应用程序在调度程序处理程序中处理异常后会锁定?

这是我的代码

    private void App_DispatcherUnhandledException(object sender, DispatcherUnhandledExceptionEventArgs e)
    {
       // log exception here
        e.Handled = true; 
    } // control is lost after executing this block

    private void App_UnhandledException(object sender, UnhandledExceptionEventArgs e)
    {
        try
        {
            Exception ex = e.ExceptionObject as Exception;                
            // log exception here
        }
        finally
        {
            Environment.Exit(-1);
        }

    }

In my App.xaml.cs I have events to handle DispatcherUnhandledExceptions (UI thread) and UnhandledException (Non UI thread). When I throw an exception inside dispatcher.Invoke, the dispatcherhandler catches the exception and handles it. I am setting e.Handled to true after logging the exception. Now the strange behaviour, if i throw the exception outside of the dispatcher.Invoke as a regualr statment, control is sent to the dispatcher exception handler,but after the method is processed the app basically loses control but I can tell its still running by looking at the stop button in vs.

one more thing, if i set e.handled to false, control is sent to the non-ui thread exception handler.

So what puzzles me is why is the application locking after handling the exceptiono in the dispatcher handler?

here's my code

    private void App_DispatcherUnhandledException(object sender, DispatcherUnhandledExceptionEventArgs e)
    {
       // log exception here
        e.Handled = true; 
    } // control is lost after executing this block

    private void App_UnhandledException(object sender, UnhandledExceptionEventArgs e)
    {
        try
        {
            Exception ex = e.ExceptionObject as Exception;                
            // log exception here
        }
        finally
        {
            Environment.Exit(-1);
        }

    }

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

指尖上得阳光 2024-12-24 23:01:55

UnhandledException 意味着您的应用程序实际上已死亡。如果您收到该事件,那么采取任何措施从该场景中恢复就为时已晚。通常,您只会使用此事件来记录错误以进行调试,并可能尝试清理一些非托管资源。

以下文章详细说明了 WPF 中的异常处理。

An UnhandledException means that your application is effectively dead. If you get that event then it is too late to do anything to recover from the scenario. Typically you would use this event only to log errors for debugging purposes and maybe attempt to cleanup some unmanaged resources.

The following article gives a detailed explanation of exception handling in WPF.

清引 2024-12-24 23:01:55

如果在 OnStartup 事件之后引发异常,则应用程序似乎能够恢复操作,如果在其间引发异常,则捕获并处理异常,但主窗口从未显示,但调试器将应用程序显示为正在运行。

我发现的最接近的解决方案是从主窗口的构造函数中删除复杂的逻辑,以允许 onstartup 事件执行并在我的 MainWindow 加载事件中执行大量加载。

It seems like the app is able to resume operation if the exception is raised after the OnStartup Event, if the exception is raised in between, the exception is caught and handled but the main window is never shown yet the debugger shows the app as running.

the closest solution I found is to remove complex logic from the constructor of main window to allow onstartup event to execute and do a lot of loading in my MainWindow load event.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文