如何干净地中止 Delphi 程序？
我有一个程序在关闭期间遇到一些问题，引发了我无法追溯到其源头的异常。 它似乎与时间相关且具有不确定性。 这是在所有共享资源被释放之后发生的，并且由于它被关闭，内存泄漏不是问题，所以这让我想知道是否有任何方法可以告诉程序在释放共享资源后立即安静地终止，而不是继续执行关闭顺序并给出异常消息框。
有谁知道这是怎么做到的吗？
I've got a program that's having some trouble during shutdown, raising exceptions that I can't trace back to their source. It appears to be timing-related and non-deterministic. This is occurring after all shared resources have been released, and since it's shutdown, memory leaks are not an issue, so that makes me wonder if there's any way to just tell the program to terminate immediately and silently after releasing the shared resources, instead of continuing with the shutdown sequence and giving an exception message box.
Does anyone know how to do that?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
在查看了 Delphi Run Time Library 源代码和 Microsoft 文档之后； 我可以证实梅森和保罗-简的评论。
关闭的层次结构如下
After looking at the Delphi Run Time Library source code, and at the Microsoft documentation; I can corroborate Mason and Paul-Jan comments.
The hierarchy of shutdown is as follows
退出进程（0）？
ExitProcess(0) ?
Halt(0) 曾经是告诉程序立即结束的好老式方法。 现在可能有一种对 Delphi 更友好的方法来做到这一点，但我 95% 确定halt(0) 仍然有效。 :-)
Halt(0) used to be the good old fashioned way of telling the program to end with immediate effect. There's probably a more Delphi-friendly way of doing that now, but I'm 95% sure halt(0) still works. :-)
如果 HeartWare 使用 ExitProcess() 的建议失败，可能是您使用的某些 DLL 不能很好地响应 DLL_PROCESS_DETACH。 在这种情况下，请尝试使用 TerminateProcess( getCurrentProcess, 0 );
一旦采取此类措施，人们可能会怀疑主题标题中的“干净”部分是否仍然经得起审查。
In case HeartWare's suggestion of using ExitProcess() fails, it might be you are using some DLL's that do not respond well to the DLL_PROCESS_DETACH. In that case, try using a TerminateProcess( getCurrentProcess, 0 );
Once you resort to such measures, one might wonder if the "cleanly" part of the topic title still holds up to scrutiny.
上次我不得不寻找这样的问题时，关闭导致了一个事件（调整大小？已经有一段时间了。）在垂死的窗口上触发，导致尝试重新绘制需要已经处理掉的东西的东西。
The last time I had to hunt a problem like this was the shutdown was a causing an event (resize? It's been a while.) to fire on the dying window causing an attempt to redraw something that needed stuff that had already been disposed of.