为什么要在对象方法中检查 Assigned(self)？答案

【问题标题】：Why would you check for Assigned(self) in object methods?为什么要在对象方法中检查 Assigned(self)？
【发布时间】：2009-06-24 20:39:46
【问题描述】：

我正在查看一些代码（Delphi 7），以下检查位于特定对象的每个方法调用的顶部：

if not Assigned(self) then
  raise Exception.CreateRes(@sAbstractError);

  { Real code for this method}

我想这会阻止我尝试在空对象指针上调用方法。但是在这种情况下，一旦我尝试访问成员数据，我就会得到一个例外，对吧？

这是我从未见过的某种标准吗？有问题的对象派生自 TPersistent。

【问题讨论】：

标签： delphi delphi-7

【解决方案1】：

您可以在空指针上调用实例方法，尽管这不是您想要刻意做的事情。当这种情况发生时，执行会非常愉快地继续进行，直到它需要访问实例数据，然后一切都顺利。

在这种情况下，检查 nil 会在过程的顶部提醒您，以便您可以执行不同的操作，例如记录堆栈跟踪。或者你可以在加注线上设置一个断点，这样你就可以深入了解发生了什么。

即，如果我有一个特定的错误，我可能会这样做，我试图追踪使用 nil 引用的位置。

经常这样做让我觉得代码有异味。

【讨论】：

【解决方案2】：

抱怨 nil 指针的明确错误比没有说明它是如何发生的访问冲突要好。

【讨论】：

+1 用于捕获 nil 指针而不是可能访问冲突。
nil 指针取消引用很难不繁荣。你不拥有那里的记忆。

【解决方案3】：

存在访问冲突场景，可能导致代码在 Self 为 nil 的内存中运行。一些程序员，而不是解决真正的问题，试图绕过使用这样的断言，以防止各种损坏。我会很好地检查该异常是否在运行时引发，如果是这样 - 你手中有错误的代码。

您可以阅读以下有关该主题的文章：When Self in Nil... You Know You are in Trouble。

另一种可能性与事件有关，您可以在此处阅读更多内容，其中包含大量此类测试的示例以及相应的解释：Multicast Events - Part 2。

【讨论】：

我不会说这个示例代码完全绕过了真正的问题。相反，它明确地突出了问题。

【解决方案4】：

这种情况肯定会导致崩溃（即操作系统异常，例如“从地址 0x00000000 读取”）。抛出一个语言异常是多余的（在这里滥用 EAbstractError 并不能让它变得更好）。

检查有效的输入参数在不安全的语言中不是一项可行的任务，因为您永远不会获得确定性，因此您对无效参数的处理将永远不会一致。（为什么在传递 nil 指针时抛出异常，而不是 0x00000001，这同样无效？）。有关此问题的更多技术讨论，请阅读 Larry Osterman 关于why not to check for valid pointers 的博客。

需要注意一个例外：在 Delphi 中，Free 方法可能会在 nil 指针上调用，这当然需要这种检查。

【讨论】：

【解决方案5】：

然后总是有可能代码在使用 nil Self 运行时不会崩溃。示例 - 如果它没有访问所有者对象的任何字段。在这种情况下，此测试将捕获原本无法检测到的问题。

不过，这还是将防御性编程发挥到了极致。我从来没有（好吧，几乎从来没有 - 只有当我在猎捕 wabbits 时...... errr...... 挤压虫子）这样做。

【讨论】：

即使我已经做到了——将非类方法当作类方法使用是一种糟糕的形式。

【解决方案6】：

似乎该方法的初衷是它成为一个抽象方法。

【讨论】：