language-agnostic - 修复常用的库函数，还是放弃呢？

Question

想象一下，我有一个带有错误的函数:

伪代码:

void Foo(LPVOID o)
{ 
   //implementation details omitted
}

问题是用户通过了 null :

Object bar = null;

...

Foo(bar);

那么函数可能会因为访问冲突而崩溃；但它也可能会正常工作。错误是该函数应该一直在检查通过 null 的无效情况。 ，但它从来没有。这从来不是问题，因为开发人员被信任知道他们在做什么。

如果我现在将功能更改为:

伪代码:

void Foo(LPVOID o)
{
   if (o == null) throw new EArgumentNullException("o");

   //implementation details omitted
}

然后那些愉快地使用该功能的人，碰巧但没有遇到访问冲突，现在突然会开始看到 EArgumentNullException .

我是否继续让人们不正确地使用该功能，并创建该功能的新版本？或者我是否修复了该功能以包含它最初应该具有的功能？

所以现在是道德困境。你有吗 曾经向现有代码添加新的健全性检查、安全检查、断言？还是您将旧功能称为废弃，并有一个新功能？

考虑一个如此常见的错误，以至于微软不得不为开发人员修复它:

 MessageBox(GetDesktopWindow, ...);

你永远不会， 曾经想在桌面上制作一个窗口模型。你会锁定系统。您是否继续让开发人员锁定用户的计算机？或者您是否将功能更改为:

 MessageBox(HWND hWndParent, ...)
 {
    if (hWndParent == GetDesktopWindow)
       throw new Exception("hWndParent cannot be the desktop window. Use NULL instead.");

    ...
 }

实际上，Microsoft 更改了 Window Manager 以自动修复错误参数:

 MessageBox(HWND hWndParent, ...)
 {
    if (hWndParent == GetDesktopWindow)
       hWndParent = 0;

    ...
 }

在我编造的例子中，没有办法修补这个函数——如果我没有得到一个对象，我就不能做我需要做的事情。

您是否冒着通过添加参数验证来破坏现有代码的风险？您是否让现有代码继续出错，得到不正确的结果？

Answer 1

问题在于，您不仅要修复错误，而且还要通过引入错误案例来更改方法的语义签名。

从软件工程的角度来看，我建议您尝试尽可能地指定方法(例如使用前置条件和后置条件)，但是一旦方法出现，规范更改是不可能的(或者至少您会检查该方法的所有出现)和一个新的方法会更好。