不行，我们怀念臭名昭著的Try Catch
为了让生活更加艰难一点，作者为Rust开发了Try Catch库。作者太幽默了。
针对 Rustaceans 的“罪恶”（Features or "Sins Against Rustaceans"）
**重现 throw和catch**：当你以为唯一的投掷与接球只会出现在高中棒球队时，我们赋予了它全新的意义——让开发者彻夜难眠的噩梦工具。Panic 恢复：因为捕获 panic 总比修复代码更有道理，不是吗？ 通用异常处理：捕获一切！谁需要类型安全？让我们欢迎更多的神秘 bug！ Finally 块：善后你的灾难，或者不善后，我们不做评判。 可读性？不存在的：这不是 bug，这是特性！在曾努力避免混乱语法的语言中，拥抱意大利面条式的回调地狱吧。
为什么？
因为 Rust 的错误处理太安全了
Rust 的 Result 和 Option 类型实在太完美了，开发者几乎被迫认真思考错误并负责任地处理它们。哪里还有运行时崩溃的刺激？Rust 应该拥抱 try-catch 的不可预测性，让我们重新体验凌晨两点调试堆栈追踪的快感——这才是真正的程序员生活。
我们想念嵌套的金字塔代码
没有 try-catch，我们被迫使用 .and_then() 和 ? 操作符编写线性、可读的错误处理代码。恶心！我们想回到深深嵌套的时代，让 try { try { try { ... } catch { ... } } catch { ... } } 这种迷宫般的代码成为维护者的终极探险。
世界需要更多的 "catch exception (e)" 笑话
在 try-catch 的世界中，可以随处丢一个泛型的 catch exception (e) 块，然后自信地称之为“错误处理”。调试几个小时后才意识到某个 catch 吞掉了一个从未记录的错误，这是一种必经的程序员体验。Rust 用户难道不配拥有这样的仪式感吗？
生活已经够难了
Rust 的 unwrap() 方法被过度污名化了。要是我们能把所有可能的错误都塞进一个 catch 块里然后一了百了，岂不美哉？当开发者不再需要担心程序是否真的正常工作时，生产力将直线上升。
Rust 需要戏剧性
rust-try-catch 将引发关于是否应该使用异常还是 Result 的激烈争论。这些争论可能会比经典的“苹果 vs 橙子”大战更有趣。目前，Rust 的论坛和 Reddit 讨论太专注于生产力了。混乱在哪里？
我花了两年时间用Rust重建我的算法交易平台，不再后悔
这个标题似曾相识，没错，就是之前那个说花了18个月用Rust重建算法交易平台，后悔死了的家伙。
坚持下来后，现在完全改变了观点。
https://nexustrade.io/blog/i-spent-2-years-rebuilding-my-algorithmic-trading-platform-in-rust-i-have-noregrets-20241205
--
From 日报小组 Mike
社区学习交流平台订阅：
Rustcc论坛: 支持rss 微信公众号：Rust语言中文社区
