除了解决问题，什么办法都试过了

# 一切手段都可行，除了解决问题 来源：https://yosefk.com/blog/all-means-are-fair-except-solving-the-problem.html 我圈子里的一位行业资深人士最近犯了一个新手错误[1](https://yosefk.com/blog/all-means-are-fair-except-solving-the-problem.html#fn1)，在代码被误用时打印了一条警告。让有经验的人毫不意外的是，关键工作流很快就彻底停止了。 原来，使用他代码的程序在退出时会打印类似"yay, done"的内容，脚本预期这是它说的最后一句话。但现在这些警告偶尔会从析构函数等地方打印出来，出现在"yay, done"*之后*，让脚本以为程序失败了。 你可能会认为这促使人们去修复被报告的误用情况——但这种想法是另一个新手错误。取而代之的是，他们迅速指出，很难知道这些警告可能从哪里冒出来，而且我们不能冒险让所有关键工作流在误用情况出现在新环境中时失败。 我的意思是，你可以用 grep 找到一个上限，而且如果你做了，并没有多少地方会显示出来。但接下来有人可能会说——事实上确实有人这么说——也许你还没有 grep 所有应该 grep 的地方，而且你找到的这些情况分属许多不同的团队，所以我们无法足够快地修复它们，等等。 一些热心的资深人士提出了几个解决方案： - 你可以在析构序列中如果打印了警告，就*再次*打印"yay, done"（这引发了一场有趣的技术辩论，讨论析构函数、__attribute__((destructor))、atexit 处理程序和其他难以言喻的恐怖事物之间的区别）。事实上，我们的行业资深人士后来得知——我发誓这不是编造的——*已经有人实现了这个方案*，在程序终止序列中打印了一些内容，必须安抚那些脚本。 - 你可以通过默认禁用警告、按需启用它们（引发了一场关于启用它们的运行时方法以及适当启用时机的辩论）。 - 你可以把这些警告写到它们自己的文件中，然后…… 当我翻完他工作聊天记录中这些热心的建议后，我们这位不幸的行业资深人士带着忧郁的微笑总结了情况："一切手段都可行，除了解决问题。"[2](https://yosefk.com/blog/all-means-are-fair-except-solving-the-problem.html#fn2)