delphi - 如何确定 Delphi 应用程序中终结期间抛出异常的位置？

Question

我正在现场与客户合作，我正在努力帮助他们解决一个复杂的问题。我希望Delphi中有一个工具或功能可以帮助我们深入了解内部工作原理来帮助我们定位问题。

以下是我们正在处理的问题的高级概述。这是一个商业应用程序，目前部署在 Delphi 5 中。在过去的一年中，该应用程序已迁移到 Delphi XE。迁移已基本完成，但遇到了一些严重错误。

应用程序本身非常庞大，有数百个单元和许多第三方和自定义组件。在我们遇到的一种特定情况下，创建主窗体，然后在显示该主窗体之前终止应用程序。结果是在终止期间发生崩溃，因为单元正在最终确定。

调试器正在中断 kernel32 的 RaiseException 函数，该函数由 NotifyNonDelphiException 调用。我们尝试设置一个不间断的断点来记录 NotifyNonDelphiException 中的调用堆栈，但这并没有给我们带来任何有用的东西。调用堆栈仅包含处理异常的方法，即 RtlRaiseStatus 和 KUserExceptionDispatcher。

我们如何识别引发 NotifyNonDelphiException 正在处理的原始异常的代码？

<小时/>

编辑:这是在一个异常实例之后捕获的两张图像。第一个是引发的异常，第二个描绘了异常对话框关闭后的 CPU 窗口。

新编辑:

自从我发布这个问题以来已经过去一周多了，各种答案给我留下了深刻的印象。对最初问题的一些评论是最有值(value)的，但一些答案本身也提供了非常丰富的信息。

我对该客户的访问已经结束，我将要求他们考虑此处发布的答案。虽然我们无法追踪错误的实际来源，但错误的原因非常明显。多年来对用户界面的调整而没有进行认真的重构，导致应用程序的登录过程不稳定。当用户取消登录时，主窗体处于部分初始化状态。当不允许该进程运行时(即用户中止登录时发生的情况)，就会出现非常严重的最终确定问题。

该公司已购买 AQTime Pro 来帮助识别 future 的问题，但需要重构登录流程，从长远来看将解决问题。

我一度考虑删除这个问题，但我选择将其发布，因为我相信其他人会发现发布的许多优秀建议内容丰富。

目前，我接受@Deltics 的回答，因为我讨厌留下一个没有答案的问题。不过，我要求这个问题的观众也考虑所有其他答案和评论，它们同样有值(value)。

Answer 1

正是出于这个原因，绝不允许异常从最终化(或初始化)部分“逃逸”。

除了极少数异常(exception)情况[原文如此]，finalization 部分中的任何代码都应包含在 try.. except 中。遇到异常时要做什么取决于您，但至少调用 OutputDebugString() 会在调试时为您提供信息，并为您提供一个设置断点的点，该断点将在仅当实际发生异常时才导致中断。

finalization
  try
    // Perform finalization processing here

  except
    on e: Exception do
      OutputDebugString('%s: $s in unit %s', [e.ClassName, e.Message, 'MyUnitName']);
  end;
end.

注意:此代码中的 OutputDebugString() 调用是我自己的“字符串友好”，包装了 Windows 单元，扩展为接受参数。

由于您的最终确定部分中可能没有此类异常处理，因此需要先将它们就位，然后才能继续。但是，此练习将提高代码的整体质量，并使将来诊断任何类似问题变得更加容易(也就是说，一旦您确定并修复了当前的异常，其他一些最终确定 异常不会抬起它丑陋的头吗？)。

此外，应用此异常处理的过程将使您有机会检查每个最终化部分，并确定是否不能以不同的方式处理它，以期消除尽可能多的最终化 尽可能的部分。

这不应被视为“不必要的开销”或“浪费时间”，而是使代码质量达到可接受标准的重要内务处理部分。

替代方法

另一种方法是管理您自己的最终确定程序列表，正如我们在引入最终确定部分之前必须做的那样。即，在当前已终结的单元的初始化部分中，将当前终结代码删除到无参数过程中，并向“终结管理器”注册该过程。

然后，在您的应用程序中，在应用程序关闭期间的适当时间调用“最终确定管理器”，以便在任何实际单元最终确定发生之前执行最终确定。这可确保您的终结过程在运行时异常处理程序仍然存在的情况下执行。

这也提供了提供更复杂的“最终确定管理器”的机会，其机制可确保最终确定过程以特定的、确定的顺序执行(如果需要)。当然，此功能取决于您如何实现自己的终结管理器。