释放应用程序时的异常控制

本文关键字：异常 控制 应用程序 释放 | 更新日期: 2023-09-27 18:05:46

对某些人来说可能是一个明显的问题，但无法找到重复的

我正在打包我一直在做的Windows窗体解决方案的最终版本，并准备好在线发布。这样做的最佳实践是什么?我们已经在打包安装文件时遇到了一些麻烦，并且在不同的pc上测试程序时遇到了障碍，包括32位和64位。

更具体地说，"throw;"命令应该被注释掉或留在最终版本中吗?这会暴露解决方案本身的任何内部工作吗?

释放应用程序时的异常控制

发布的应用程序不应该在发生异常时崩溃。您可能想要通知用户出了问题并记录异常，但又不想崩溃!通知用户应该以友好的方式完成，而不是仅仅将exception.ToString()放入消息框。

添加Application.ThreadException或AppDomain.CurrentDomain.UnhandledException处理程序来处理应用程序中的所有异常是一个很好的做法。如何确切地做到这一点，是在以下线程回答:捕捉应用程序异常在Windows窗体应用程序然而，确保你的应用程序在一个可用的状态下生存，即以适当的方式处理异常。

我通常添加一个预处理指令来处理应用程序级别的异常，因为我希望它们在调试时出现。例如:

#if !DEBUG 
   Application.ThreadException += new ThreadExceptionEventHandler(MyHandler);
#endif

还应该提到，如果您的代码片段预计可能会发生异常，例如网络通信错误，则应该显式地处理这些片段。我想说的是，我们不应该仅仅因为在应用程序级别配置了一个未处理的异常处理程序就完全忘记异常处理。

保持所有异常处理的完整性。

将事件添加到应用程序中的起始表单，并附加到应用程序中。UnhandledException事件。当异常向上抛出堆栈时，该函数将被触发。

这是通知用户应用程序已经崩溃的点。在此记录错误，然后优雅地中止。

你关于揭示内在的观点，由你来决定。如果您愿意，您可以混淆源代码，但是如果您以发布构建模式发布，并且不提供. pdb，那么这是第一步。

最终，DLL/EXE可以被反编译，所以这取决于你。调试模式将比发布模式揭示更多，但不会更多。

理想情况下，您应该捕捉到throw;抛出的更高的任何东西。仔细检查您的代码，并尝试确保正确处理抛出的异常。未处理的异常会被记录下来——你可以在Windows事件查看器中看到这些信息。根据您放入的细节，未处理的异常可以提供有关应用程序内部工作的线索。然而，我建议未处理的异常是一个糟糕的信息来源，任何想知道你的应用程序是如何工作的人都可以简单地反汇编它，除非你混淆了它。

一些异常不能被try/catch块的周围代码捕获，所以你的应用程序也应该实现一个未处理的异常处理程序。这使您有机会向用户显示错误消息并对异常进行处理—记录它，将其发送给支持，丢弃它，等等。

相关文章：