不要将程序钉在直立位置

这篇具有很好参考价值的文章主要介绍了不要将程序钉在直立位置。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

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文章来源地址https://www.toymoban.com/news/detail-440459.html

到了这里,关于不要将程序钉在直立位置的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 关于position:fixed定位的位置不对的问题(即没有按照浏览器的窗口进行定位)

    问题: 今天在开发过程中发现元素使用 position: fixed 时位置有问题,位置跟我写的位置对不上,后面在 MDN 上面找到了答案,下面是关于 position: fixed 的描述: fixed: 元素会被移出正常文档流,并不为元素预留空间,而是通过指定元素相对于屏幕视口(viewport)的位置来指定元

    2024年02月15日
    浏览(45)
  • 相对位置编码之RPR式:《Self-Attention with Relative Position Representations》论文笔记

    😄 额,本想学学XLNet的,然后XLNet又是以transformer-XL为主要结构,然后transformer-XL做了两个改进:一个是结构上做了segment-level的循环机制,一个是在attention机制里引入了相对位置编码信息来避免不同segment的同一位置采用相同的绝对位置编码的不合理。但无奈看到相对位置编码

    2024年02月17日
    浏览(41)
  • 用于多视图 3D 对象检测的位置嵌入变换(PETR: Position Embedding Transformation for Multi-View 3D Object Detection)

    本文PETR (PETR: Position Embedding Transformation for Multi-View 3D Object Detection)是对DETR3D (3D Object Detection from Multi-view Images via 3D-to-2D Queries)的改进,将2D转换至3D,还存在三个问题: (1) 空间与多视图之间的信息交互依赖于3D参考点估计的准确性,使得采样的特征超出了对象区域,无法投影

    2024年02月07日
    浏览(50)
  • 【原生小程序小程序开发中,块内容使用position绝对定位之后 不显示】

    原来写法 解决:在map外面包一层以及整体在外面包一层+定位修改为static+z-index

    2024年03月10日
    浏览(51)
  • 做程序员有前途么? 当今社会, 我还要不要做程序员?

    本文成于2023年, 基于当前的社会形势, 以及笔者自己的工作经验而成.  笔者的职业是程序员, 有很多人在考虑要不要做程序员, 公司也有很多程序员, 就连程序员自己也会考虑: \\\"程序员到底有没有前途, 要不要转行, 以后怎么发展, 遇到中年危机怎么办\\\" 之类的问题.  仅以此篇

    2024年02月08日
    浏览(58)
  • 10 年程序员的告诫:千万不要重写代码!!

    对重写代码说不。 以下为译文: 1、重写代码消耗了12个月! 我们从头开始重写代码浪费的时间。 你能想象在软件行业,12个月的时间没有任何新产品推出,没有任何新版本更新吗? 真的,我不由自主地问自己这个问题: 在这个快速发展的世界里,12月的时间能让我们做多少

    2024年02月08日
    浏览(37)
  • [JVM] 5. 运行时数据区(2)-- 程序计数器(Program Counter Register)

    JVM中的程序计数器(Program Counter Register)是对物理PC寄存器的一种抽象模拟。 它是一块很小的内存空间,几乎可以忽略不记。也是运行速度最快的存储区域。 在 JVM 规范中,每个线程都有它自己的程序计数器,是线程私有的,生命周期与线程的生命周期保持一致。 任何时间一

    2024年02月16日
    浏览(87)
  • 为什么要将应用微服务化

    其实在十多年前,“架构师”并不是一个需求很大的职业,一来那时还没有“全民App”级别的应用,除了三大门户网站以外,其他的网上应用业务压力并不大;二来也没有现如今这么丰富的技术选型,几乎清一色的PHP(坊间一直流传着PHP是世界上最好的语言这个说法,我08年左右

    2024年01月17日
    浏览(48)
  • 为什么要将应用微服务化?

    其实在十多年前,“架构师”并不是一个需求很大的职业,一来那时还没有“全民App”级别的应用,除了三大门户网站以外,其他的网上应用业务压力并不大;二来也没有现如今这么丰富的技术选型,几乎清一色的PHP(坊间一直流传着PHP是世界上最好的语言这个说法,我08年左右

    2024年01月18日
    浏览(47)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包