文章调侃C++没有像其他语言那样直接提供try...finally语法，而是通过其他方式实现类似功能，暗示C++的解决方案不够优雅但也能达到目的。

标题：其他编程语言都有try...finally，C++说"我们家也有"——The Old New Thing

主要内容： 1. 文章对比了C++与其他主流编程语言（如Java、C#、Python、JavaScript）在异常处理机制上的差异 2. 重点分析了try...finally结构的实现方式： - 其他语言直接提供try...finally语法 - C++通过析构函数实现类似功能，如使用WIL库的wil::scope_exit

3. 详细说明了不同语言在finally块/析构函数抛出异常时的行为差异：

   • Java/Python/JavaScript/C#：新异常会覆盖原异常
   • C++：若析构函数因异常退出，程序将终止

4. 作者指出：

   • C++的RAII机制提供了作用域退出时的自动清理
   • 但在析构函数中抛出异常存在风险
   • WIL库提供了scopeexitlog作为安全替代方案

5. 文章还提到：

   • 不应在C++中使用C语言的try/finally结构
   • 析构函数的异常行为是C++的独有特性

注：删减了与主题无关的导航菜单、评论区和广告内容，保留了核心的技术分析和对比。

以下是评论内容的总结，平衡呈现不同观点并保留关键引用：

1. 关于C++析构函数与finally的对比

   • 支持析构函数优于finally：
     • "析构函数只需记住一次释放资源，而不是每个finally子句"（Destructors are vastly superior...）
     • "语法更简洁，减少嵌套，处理分支和条件初始化更简单"（Syntax is also less cluttered...）
   • 认为析构函数不完全等同finally：
     • "析构函数实现finally风格的清理，但它们不是finally"（destructors implement finally-style cleanup...）
     • "C++只是碰巧用同一工具处理两者"（C++ just happens to use the same tool...）

2. 其他语言的替代方案

   • Swift的defer方案：
     • "更通用的defer块，在作用域结束时执行"（there's a more universal defer { ... }...）
   • Python版本过时问题：
     • "这篇文章有多老，3.2版本还被称为'现在'？"（how old is this post that 3.2 is "now"?）

3. 异常处理机制的批评

   • 对finally块中异常覆盖问题的批评：
     • "原始异常几乎总是你关心的，finally的异常可能掩盖根本原因"（The error you want to log...）
     • "Java中finally抛出的异常会抑制原始异常，而不是丢弃"（exception thrown in finally block in java will have the original as suppressed）
   • C++的极端处理方式：
     • "C++通过直接崩溃做得更糟"（C++ of course did much worse by just crashing...）

4. 其他观点

   • 对C++语法的质疑：
     • "我想知道C++语法是否最终会变得可读"（I always wonder whether C++ syntax ever becomes readable...）
   • 幽默/讽刺观点：
     • "谁需要finally，我们有goto"（Who needs finally when we have goto?）
     • "换句话说：Footgun #17421 Exhibit A"（In other words: Footgun #17421 Exhibit A.）

5. 潜在问题警告

   • 析构函数中调用回调的风险：
     • "迟早有人会违反异常要求，程序会立即终止"（Sooner or later someone will violate the requirement...）
     • "在迭代数据结构时调用回调需谨慎"（care must be taken when calling arbitrary callbacks...）