不要将程序钉在直立位置

Don’t Nail Your Program into the Upright Position
I once wrote a spoof(恶作剧) C++ quiz（测验）, in which I satirically（讽刺地） suggested the following strategy for exception handling:

By dint of plentiful (大量的)try…catch constructs throughout our code base, we are sometimes able to prevent our applications from aborting. We think of the resultant（结果） state as “nailing the corpse（尸体） in the upright position.”

Despite my levity, I was actually summarizing a lesson I received at the knee of Dame Bitter Experience herself.

It was a base application class in our own, homemade C++ library. It had suffered the pokings of many programmers’ fingers over the years: Nobody’s hands were clean. It contained code to deal with all escaped exceptions from everything else. Taking our lead from Yossarian in Catch-22, we decided, or rather felt (decided implies more thought than went into the construction of this monster) that an instance of this class should live forever or die in the attempt.

To this end, we intertwined multiple exception handlers. We mixed in Windows’ structured exception handling with the native kind (remember __try…__except in C++? Me neither). When things threw unexpectedly, we tried calling them again, pressing the parameters harder. Looking back, I like to think that when writing an inner try…catch handler within the catch clause of another, some sort of awareness crept over me that I might have accidentally taken a slip road from the motorway of good practice into the aromatic but insalubrious lane of lunacy. However, this is probably retrospective wisdom.

Needless to say, whenever something went wrong in applications based on this class, they vanished like Mafia victims at the dockside, leaving behind no useful trail of bubbles to indicate what the hell happened, notwithstanding the dump routines that were supposedly called to record the disaster. Eventually — a long eventually — we took stock of what we had done, and experienced shame. We replaced the whole mess with a minimal and robust reporting mechanism. But this was many crashes down the line.

I wouldn’t bother you with this — for surely nobody else could ever be as stupid as we were — but for an online argument I had recently with a bloke whose academic job title declared he should know better. We were discussing Java code in a remote transaction. If the code failed, he argued, it should catch and block the exception in situ. (“And then do what with it?” I asked. “Cook it for supper?”)

He quoted the UI designers’ rule: NEVER LET THE USER SEE AN EXCEPTION REPORT, rather as though this settled the matter, what with it being in caps and everything. I wonder if he was responsible for the code in one of those blue-screened ATMs whose photos decorate the feebler blogs, and had been permanently traumatized. Anyway, if you should meet him, nod and smile and take no notice, as you sidle towards the door.

By Verity Stob

不要将程序钉在直立位置
我曾经写过一个恶搞C++测试，在其中我讽刺地提出了以下异常处理策略：
通过大量的try…catch构造贯穿我们的代码库，有时我们能够防止应用程序中止。我们认为由此产生的状态是“将尸体钉在直立的位置。”
尽管我很轻浮，但我实际上是在总结我在痛苦经历女爵士膝下学到的一堂课。
它是我们自己的、自制的C++库中的一个基本应用程序类。多年来，它遭受了许多程序员的指责：没有人的手是干净的。它包含一些代码，用来处理所有其他事物的转义异常。在《第二十二条军规》中，我们以尤萨良为榜样，决定，或者更确切地说，我们觉得（决定意味着比构建这个怪物更多的思考），这个类别的一个例子应该永远存在，否则就会在尝试中死去。
为此，我们将多个异常处理程序交织在一起。我们将Windows的结构化异常处理与本机类型混合在一起（还记得在C++中__try…__except吗？我也不记得）。当事情出乎意料地发生时，我们试着再次调用它们，更加用力地按下参数。回想起来，我喜欢这样想，当写一篇内心的尝试。。。在另一个的catch子句中，我意识到我可能不小心从良好实践的高速公路上走了一条支路，进入了芳香但不健康的疯狂车道。然而，这可能是回顾性的智慧。
不用说，每当基于此类的应用程序出现问题时，它们就会像码头边的黑手党受害者一样消失，留下任何有用的泡沫痕迹来表明到底发生了什么，尽管据说是为了记录灾难而调用的转储例程。最终——很长一段时间——我们对自己所做的事情进行了评估，并感到羞愧。我们用最低限度和稳健的报告机制取代了整个混乱局面。但这是许多撞车事故。
我不会为此打扰你——因为肯定没有人会像我们这样愚蠢——但我最近在网上与一个家伙发生了一场争论，他的学术职称宣称他应该更清楚。我们正在讨论远程事务中的Java代码。他认为，如果代码失败，它应该在原地捕获并阻止异常。（“然后用它做什么？”我问道。“把它煮成晚餐？”）
他引用了UI设计师的规则：永远不要让用户看到异常报告，就好像这解决了问题，因为它是大写的。我想知道他是否对其中一台蓝屏自动取款机的代码负责，这些自动取款机上的照片装饰着虚弱的博客，并受到了永久性的创伤。不管怎样，如果你遇到他，当你侧身走向门口时，点头微笑，不要理会。
作者：Verity Stob