javascript - 使用断言在 node.js 中进行防御性编程

Question

考虑到有时 node 中的错误消息特别无用，我喜欢在我的函数中自由地使用断言，以便尽快发现编程错误，并且我可以得到通常可以查明问题的消息。

function doSomething(arg1, arg2){
  assert(!arg1, "arg1 is undefined");
  assert(!arg2, "arg2 is undefined");
  assert(!arg1.expectedFn, "arg1 does not have expectedFn");

  arg1.expectedFn(function(blah){
    ...
  }
}

这在 node/javascript 程序中是不是特别糟糕？这对性能有影响吗？

Answer 1

(这更像是一种观点，而不是事实帖子，所以请接受它的值(value))

断言肯定对性能没有任何好处，但适度使用我怀疑它们是否会产生足够严重的影响。也就是说，一般来说，只要有可能，良好的测试覆盖率就比断言更可取。此外，您编写的断言不应与运行时自然抛出的错误相比是多余的，除非它们特别不透明。

让我们考虑一个修改(并且有些人为的)版本的 doSomething -

function doSomething(arg1, arg2){
  var res = arg1.expectedFn(function(blah){
    ...
  }
  return res + arg2;
}

我认为检查 arg1 是否存在或它包含一个函数名 expectedFn 是没有意义的。如果其中任何一个都未定义，javascript 运行时将抛出一个相当容易理解的 TypeError ，它会准确说明发生了什么；断言是多余的。

但是，您可能会发现在此处测试 arg2 是可取的。假设它是未定义的，并且 res 是一个字符串或数字 - 然后您最终会在字符串中附加“未定义”，或者返回 NaN。两者都是相当微妙的错误，可以存在很长时间而没有人注意到 - 如果您希望它早点失败而不是晚点以进行调试，那么您可能需要添加一些断言以确保它是正确的类型。

一般来说，如果您关心严谨性，我相信在编写综合测试时会更好地使用精力:编写完全涵盖调用 doSomething 的情况的测试可能会带来更好、更健壮的开发过程比断言。在少数情况下断言是合适的，但它们仅限于格式错误的结果可以存在很长时间而没有任何直接错误但仍会导致不良副作用的情况。