最近，我回想起了自己最初参与故障排除工作时用到的一些脚本。当时我自己也还很菜，但我记得当时觉得它们很疯狂。这个脚本的作用是将一个值注入到特定位置（可能是/proc ？），从而修改硬件。它看起来有点像这样：
insert_value put value in location X if catch error insert_value X+1 else return X
为了简洁起见，我用递归编写了伪代码，但你明白我的意思。如你所见，它会检查写入某个位置是否返回错误，如果返回错误，它会递增该位置并重试。
使用异常处理作为主要条件是……编写脚本的一种方法！我会先编写脚本来检查位置是否存在，然后再写入：
insert_value if location exists put value in location X return X else insert_value X+1
现在，我要为第一种方法辩护，用七个字来概括。不，依赖错误信息似乎会导致后续问题，尤其是在更新改变了错误内容或呈现方式的情况下。或者，就像我之前排查的原始脚本一样，系统更新导致这些错误被屏蔽，从而彻底破坏了脚本。
我把这种方法（或许有点儿戏谑）称为“错误驱动开发” ，它的普及程度比我预想的还要高。几年前，一位同事跟我解释过，你永远无法验证所有事情，所以有时你会处理异常。我记得我当时觉得这话没错，但把错误检查作为主要的条件逻辑？这感觉有点奇怪。这就像把防御性编程完全颠倒过来，把所有最佳实践都抛到九霄云外去了。
我预计“氛围编码”的情况也会变得更糟。这就像法学硕士（LLM）行业的NFT：一种愤世嫉俗的、最后一搏式的尝试，试图为不可持续的技术找到一个令人信服的用例。至少那个初级实习生写代码的技术会进步一些。
作者： Ruben Schade ，悉尼，2025 年 6 月 8 日。