不要僵直钉死你的程序

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机中的一台蓝屏了的照片,并造成了永久性创伤。无论如何,如果你见到了他,点头、微笑、不用声张,就像你走向这道门一样。

0%