【发布时间】：2009-03-02 08:57:41
【问题描述】：
当调试任何过程/函数/方法中的某些代码时发生未处理的异常时，调试器会停在那里并显示消息。
如果我现在继续一步一步调试，执行会直接从产生异常的那行跳转到当前过程的结尾（如果没有 finally 块）。
继续当前程序的下一行不是很好吗？
为什么要跳到过程的末尾并继续调用过程？ 这只是设计使然还是有充分的理由？
【问题讨论】：
【发布时间】：2009-03-02 08:57:41
【问题描述】：
异常是意外情况，这就是停止处理的原因。
跳转到程序末尾是一条不可见的 finally 语句，用于释放任何本地“分配”的内存，如字符串、接口、记录等。
如果要处理异常，则必须使用 try .. except 语句封装可以给出异常的调用，并使用“on”子句仅处理要处理的特定异常。
在 except 中，您可以检查调试器中的变量，如果需要，您可以在代码中再次引发异常。
【讨论】：
通常，未捕获的异常将在堆栈上的每个函数中执行隐藏的“finally”，因为它“展开”到异常处理程序。这会清理每个堆栈帧中的局部变量。在像 C++ 这样具有资源获取即初始化范式的语言中，它也会导致析构函数运行。
最终，在调用堆栈的某处，异常将被处理程序捕获。如果没有明确的，系统提供的将杀死进程，因为它还能合理地做什么？
【讨论】：
-
这正是 Delphi 中发生的事情。 “end”行是调试器突出显示的，表示函数的结尾，字符串和其他编译器管理的类型被破坏。它被实现为一个 try-finally 块。
抛出异常是一种表达“发生意外的事情。我不知道如何处理”的方式。在这种情况下，最好不要做任何事情（除了抛出异常）而不是尝试继续，不知道你在做什么是否正确。
在现实生活中，您也有同样的情况：如果有人让您用希伯来语（或您不知道的某种语言）数到 10，您只会说您不知道。无论如何，您都不要继续尝试。
【讨论】：
我希望它跳转到 proc 的末尾，然后跳转到调用 proc 的 except 或 finally 块。它真的在调用过程中继续，就好像什么都没发生一样吗？它使用什么作为返回值（如果是函数调用）？
在原始 proc/function 中继续下一行将是一件非常糟糕的事情 - 这意味着代码在调试器中的执行从根本上与在发布时不同（异常确实会导致执行退出该过程/功能，除非有一个例外/最终块）。为什么调试应该让你完全忽略异常？
【讨论】：
-
它在proc的最后执行一个隐藏的“finally”来清理一些局部变量
-
Jon：当然，Debugger 和 Release 的行为必须相同。我指的是调试器，因为在那里您可以看到代码执行的位置。一个隐藏的“finally”来清理导致异常的 proc 是有意义的。
-
@Holgerwa：但是我不明白你为什么建议它应该跳到当前程序的下一行。为什么它会那样做？这表明忽略异常。
-
Jon：我不想建议这是一个更好的方法，我只是想知道为什么它会跳到 proc 的末尾并且不知道隐藏的 finally 语句找不到原因。知道了这一点，现在当然很清楚了。我只是没有看到会导致它这样做的“机制”。
-
@Holgerwa：好的，那是有道理的:)
它必须展开堆栈才能找到处理程序。
我同意这是非常烦人的行为。继续不是一种选择，但如果调试器指向抛出它的地方并且局部变量仍然完好无损，它肯定会让生活更轻松。显然，下一步将是最后隐藏，而不是下一行。
我只是希望能够尽我所能检查导致它的原因。不久前，我只是在与此作斗争。文本解析，我知道有问题的字符串不包含非数字字符（理智限制意味着溢出情况永远不会发生，这是我的数据文件，我担心的是糟糕），所以我没有'不要在 StrToInt 周围放置一个异常处理程序——这是什么废话，它不是一个有效的数字？？？？？？是的——例程不会用缓冲区中的任何非数字来调用它——但是一个空字符串里面没有任何非数字！
【讨论】：