您已经发货，遇到了罕见的段错误。指针检查还是放手去做？

9

您已经发货，断言被关闭，您收到一个罕见的崩溃报告，指示代码中发生了空指针冲突。在开发环境中，问题将被断言所捕获。

您所拥有的只是一份崩溃报告，因此重现该问题几乎是不可能的。追踪回溯并没有提供任何有关崩溃为什么首先发生的线索。

选项：-添加指针检查以防止崩溃。这样可以防止崩溃，但是您可能甚至根本不知道为什么会发生崩溃。-让它飞起来，希望它在repro场景下再次发生

假设该应用程序不适合引导导弹或自动制动系统...

您会选择哪一个？

bug pointers

— MM01
source

除非是理论性的，否则如果要解决此问题，将崩溃报告和相应的代码文件（也许在Pastebin.com上）发布到Stack Overflow网站上可能会很方便...

— Tamara Wijsman 2010年

2

@TomWij：别这么认为..很可能会因为“过于本地化”而关闭

— Naveen

@Naveen：也许...我不是常规的SO访问者，所以这是SU介意的评论。

— Tamara Wijsman 2010年

1

@Naveen：过于本地化意味着过于区域化，这是关于地理而不是问题的专业化。但是，这个问题可能会因主观而在SO方面解决。

— Maniero

7

我选择了第二种方法。如果在崩溃发生时NULL指针是意外的，则隐藏崩溃是没有意义的。在大多数情况下，此NULL指针只是其他错误的症状之一。如果我们使用NULL指针将其隐藏，请检查几乎可以确定是否有其他东西会损坏。如果您知道每次崩溃的地点，而不是在某个随机的地方，我觉得您有更好的机会抓住这种情况。

— 纳文
source

1

我本人倾向于这种观点。用户的看法让我感到担忧。崩溃显然似乎出了点问题。但是，如果某项功能的计算完全错误，这也将引起注意。

— MM01 2010年

2

在我看来，即使用户偶尔会因崩溃而感到恼火，但如果它提供了错误的结果（可能会引起注意），他们也会感到非常沮丧。

— Naveen

尽早崩溃，它可以帮助您发现问题，并帮助用户减少数据丢失

— Spudd86

我也将使用valgrind找出我在做错什么（或者至少我会尝试，在任何情况下都可能会发现一些您应该解决的问题）我会添加其他断言来尝试尽早捕获NULL指针，要求用户尝试运行断言已打开一段时间的构建，以查看是否可以使它更早崩溃

— Spudd86

3

崩溃多久发生一次？在某种晦涩的情况下，这种情况只发生在众多客户中吗？有什么后果（数据丢失，系统崩溃）？如果在一百万个案例中每1个事件发生一次，而他们只需要重新启动应用程序并且没有数据丢失，那么您可能就不需要修复它-像这样保留它。
添加断言并将其发送给所有客户的成本（时间和金钱）有多昂贵（如果只有一部分客户获得了新版本，那么其余客户可能会陷入未检查的null问题）？发现问题的机会是什么？如果您只是在代码中进行随机检查以希望捕获错误，那么这是一个不好的做法...
问题可以在客户的机器上重现吗？您可以访问该机器吗？这可能真的很有价值
查看您的崩溃报告，并确保所提供的信息有用，并且可以帮助您诊断问题

— 维克多·赫尔杜加奇
source

2

_{在开发环境中，问题将被断言所捕获。}

_{按照特定的顺序，它会被捕获并修复，但是从未捕获到当前的跟踪。

您应该能够看到故障转储出了什么问题，是否检查了参数等等？}

可以根据您要投入的时间来完成这些额外工作：

— 塔玛拉·维斯曼（Tamara Wijsman）
source

1

这篇文章不是关于解决问题的方法，而是在假设情况下的行动过程（即，在分配的时间范围内，无法推断出问题的根源）。

— MM01 2010年

2

这些天来，我在assert（）打开的情况下发货。它的成本不高，在敌对的情况下可以使生活变得更加轻松（即，客户的环境通常比开发或QA环境更具敌意）。

— 米奇·海尔（Mitch Haile）
source