Delphi-try-finally块是否由编译器保证正确执行？

我知道这也是在其他话题上讨论过的，我要问的正是这个问题的标题

是否存在try/finally不执行finally的情况

 try
  //some error here
 finally
  //code that MUST be executed
 end;

我不是在说如何尝试..除了/最后必须使用块，我只是在问这是否会发生

---

LE:Application.Terminate/拔下计算机是特殊情况。

如果电源丢失（例如，如果拔下计算机，但它没有电池，并且没有连接到UPS），则很可能不会运行

finally

块。主要的操作系统或驱动程序故障（如BSOD）也可能导致这种情况。然而，

try..finally

构造的整个思想是，即使在

try

块中出现异常（任何类型），也要运行

finally

块。如果

try

块中存在

exit

语句，

finally

块甚至会运行。

try..finally

保证finally块中的代码将执行，而不管受保护块中发生任何异常。如果进程在最终块可以执行之前被终止，例如通过

TerminateProcess

或关闭电源，则这当然不适用。受保护块中的无休止循环也可能会阻止finally块的执行。

如果您的应用程序导致DEP（数据执行防止）异常，我认为windows不会允许您继续。您的进程将被破坏，而不执行finally部分。你的过程只是“消失”。但是，这与编译器做了什么或没有做什么无关。

一旦输入try/finally，finally块将在执行离开try/finally之前执行。

@RBA:什么，当然？编译器无法保证主机（硬件/操作系统/驱动程序）正常运行。。。但是，我确实相信，如果一个常见的

引发ESOMEEException.Create（…）

在

try

中被击中，您可以“保证”运行

finally

块。+1。如果可以的话，我会给“黑洞”参考号再加一个+1。）请注意，当您的计算机被吸入黑洞时，由于未能完成“finally”部分而导致的内存泄漏与可能出现的其他问题相比变得微不足道。编译器无法保证世界末日或您的PC之外的任何事情。但在所有重要的情况下，也就是当finally块仍然可以做一些有用的事情时，它将被执行。我在看这个问题-似乎Java开发人员没有考虑虫洞/世界末日/等等。我必须承认，Delphi开发人员有幽默感，但最终不是所有的代码都能得到保证。例如，在finally部分中可以有3条语句，然后在第二条语句上放大。第三条语句将不会执行。一个很好的例子是尝试释放未分配的对象。保证更有力。退出、中断或继续超出finally将导致finally块运行。我想后藤也是如此，但我不知道，因为我从来没有用过后藤。也许@Andreas知道，因为我看到他使用goto！；-）我怀疑后藤会不会进入最后的。。。就像进入FOR循环一样，循环计数器没有初始化。goto不像CONTINUE、BREAK和EXIT那样“结构化”。@Chris，事实上，保证的是最终块将被输入，而不是它将运行到完成。只是尝试了：从try块中跳出的goto不会编译。这就解决了这个问题。即使asm块中的JMP也不会编译。哇！finally块将开始执行。只希望不会有什么事情发生。你想给他们都买一杯啤酒吗？@Henk我经常看到的一个错误是在一个数据库中放了很多代码。通常，每个最终都应该处理一个对象。一旦在抛出的finally块中有了代码，您就有麻烦了。当然，如果真是这样的话，那可能不是世界末日。也许你不在乎，我不会允许的。但我见过很多在finally中做得太多的狡猾代码。@henk“you”实际上是指第三人称you，而不是第二人称，即one或the French on。我讨厌英语中的这种缺陷。或者，也许是我无法发现自己缺乏补偿，这让我讨厌。