Don’t Nail Your Program into the Upright Position
我有次写了一个C++恶搞比赛，我讽刺地建议了以下的异常处理策略：
凭借遍布我们整个代码库的
try...catch的结构，我们有时能够阻止程序的终止。我们把这种状态认为是“直立钉尸”。
尽管我的草率，实际上我还是总结了从这位祥林嫂(Dame Bitter Experience——或者叫艰苦岁月女？🥵)膝上学到的一课。
这是我们自制的C++库，是应用程序的一个基类。多年以后它被千“猿”所指：没有谁的手是干净的。它包含的代码把任何事情的异常都做了避开处理。通过Yossarian的第22条军规(Catch-22)作为指导，我们决定，或者说倾向于这个类的一个实例要么总是活着，要么赶紧死掉。(决定暗示更多想法，而不仅仅是进入这只怪物的结构)
为此，我们把多个异常交织在一起处理。我们把Windows的结构化异常与原生的类型混合在一起处理(记住C++中的__try..__except？我都没有)。当有意外抛出时，我们尝试再次调用，更难压入参数。回头看，我喜欢把一个try...catch处理写到另一个catch语句中，鬼使神差的让我可能从原本良好做法的高速公路走到了一条支路，进入一条芳香四溢但很不健康的疯狂车道。然而，这很可能是事后诸葛亮。
不用说，程序无论何时出错了，基本都是因为这个类，它们的消失就像是在码头的黑手党遇害者，只留下没用的气泡，鬼才知道发生了什么，尽管据说转储例程会记录这场灾难。最终——很长的最终——我们盘点了所做的事情，并因此感到羞愧。我们用一个小巧且健壮的报告机制替换了这个肮脏的家伙。但这是十分让人崩溃的。
我不会打扰你——去确认还有谁会向我们一样蠢——但我最近在线上和一个家伙讨论问题，他的学术职称表明他应该很牛逼。我们一起讨论了Java代码关于远程传输。如果代码失败了，他认为，应该在原地捕获并阻止异常。(“接下来做什么？” 我问。“拿去做夜宵么？”)
他引用了UI设计师的法则：永远不要让用户看到异常报告(大写)，看似好像解决了问题，但这些大写的和任何内容又是什么。我想知道他是否会对这段代码负责：就是大量ATM机中的一台蓝屏了的照片，并造成了永久性创伤。无论如何，如果你见到了他，点头、微笑、不用声张，就像你走向这道门一样。
