哈哈哈, 原来 cloudflare 写代码也用 unwarp() 呀

不太懂唉 大佬能细说下嘛

那是 unwrap()

unwarp()没绷住

我的评价是：? (操作符)

用 unwrap() 从来都不是问题，问题是如何正确用 unwrap()。

致命性的、不可恢复的、编码性的错误（ Error ）就应该用 unwrap() 直接抛掉，强制终止运行状态不正常的进程，打印堆栈和 dump 以便后续查证；而一般性的异常（ Exception ）才应该用 Result 正确 handle 。

@MAVETRICK #3 手滑拼错了别在意哈哈

@chenxuuu 这人说话 GENAI 味儿好浓..

看起来是个工程性难题。看楼上截图的解释，我还在思考用 clickhouse 推送配置是个什么操作。哈哈哈，水平差太远了，完全跟不上思路。

该用就用, 不过我一般会 expect 带上信息

@qi1 rust 中有个函数 unwrap ，在碰到 error 和 none 这两个值的时候，就直接杀进程了（类似 Java 的排除异常，而没有 catch ）。一般项目中为了防止这种情况，多半会用 unwrap_or 或者 unwrap_or_default ，这样在出现问题的时候会有默认值或者回退值。不过那篇文章我没有完全看完。完全怪这个函数我个人觉得应该不是主要问题。

@kapaseker You're right. The problem is that after an error is introduced, other nodes lack protection mechanisms, for example:
1. The BOT management module design lacks exception tolerance, which stems from two issues: an implicit assumption about the scale of the input data and an exception handling strategy when the assumptions are exceeded.
The current approach is to stop upon failure.
2. Internal changes lack a global impact assessment. For example, the optimization and adjustment of ClickHouse's permission management might affect surrounding coupled components. Could you run a real query in the test environment to test this?
3. Insufficient monitoring and fault drills. This internal anomaly was misdiagnosed as a DDoS attack, which affected the processing time.

unwrap 是一坨屎一样的东西，我就是因为这个，把项目推了，用 c++重写，写了快 7 万行了，还行
设计这个语法的脑子有屎，是整天写脚本程序的玩意吗？
任何生产环境的服务，谁敢错误就退出，有大病
rust 完全是一个 shit ，无比恶心

@victorc 这是个可选项，又不是必选项

@victorc 写了七万行还不明白这个设计只能说你的能力也就是个入门的搬砖工。遇到没法恢复的异常，就应该尽快把异常暴露出来。生产环境更是如此，难道架构和 infra 设计稳定性的时候是靠服务自身的稳定性来保障全局的可用性？

@michael2016 ClickHouse 权限影响范围应该挺大的,全量测试不现实.那工作量,赶上系统重构了.

@chenxuuu 比较认同 Guanlan 的回复,就本次事故,fearture file 没有容错机制,比 sql 审查影响大.容错机制是建制过程,是为了防止 sql 、代码等不规范,造成问题的手段.

@victorc 我就知道有这个回复，unwrap 就是一坨。我可以不用，但我不能确保其他人不用，尤其是那些第三方依赖的 unwrap 。也不能怪第三方作者什么，在他们接触的场景里，一些 case 确实不会出现。最重要的，用了它后的错误信息一点也不直观，出了事故想要找在哪个位置一脸懵逼。

@livid #12 楼 这个是不是 ai 回复

读完了整个 report ( https://blog.cloudflare.com/18-november-2025-outage/ )，感觉楼主有点标题党，根本原因是数据库变化导致配置生成了错误的配置文件，这个 unwrap 出现在读配置文件的地方，如果不是这里崩溃那反正后面也要死。

更大的问题是这个 bot 过滤功能不是完全必须的，但是和关键的 CDN 功能没有解耦，这个 report 里面已经说他们会加入更多的功能 kill switch 来解决。

@jworg 首先大部分语言都提供了主动 crash 的功能,

@victorc 同意一半不同意一半。说实话这事是各方面都有问题，单说 unwrap 的话是开发人员的问题，不能就这么说是语言的问题。单论代码，那些经常说出现不可处理的异常时就应该把异常暴露出来的人，这话我也认同，但是暴露的方式只有杀死进程这一种办法吗？一个正常的商业公司生产环境这么搞真的是不怕死，暴露异常的方法多了去了，cf 这次是自己没处理好，你如果要说任由服务死掉就能暴露问题，那为啥 cf 自己一开始还以为是超大的 ddos 攻击而不是立马定位到问题。生产环境是非常复杂的，一旦死掉你要面对的问题远比找到那个 bug 多，出问题了自动降级，重启扩容回退三板斧才是通用的。不是让你服务死那等你找到 bug 修完 bug 才恢复，而是设计就要考虑好你这些所谓不可处理的异常如果发生了怎么主动告警、描述问题、定位问题，这当然不是简单事，但也不是随随便便一句无法处理就可以让程序死掉的借口

这玩意好处就是，简历可以写上了解 unwarp+panic 这种小白不懂的组合

按他的命名逻辑，名字应该改成 option.unwarp_or_panic() 叫 unwarp_or_crash() 也特

语言附送的技能点 跪安吧

@jhdxr 没找到回复的对象，才发现早就 block 了。

用不着和这人犯气，纯口嗨的，有 Rust 关键词出现的帖子必来踩一脚，辩不过就玩消失，下个贴子继续骂

关键是骂的有道理（ Rust 黑点不少）也就罢了，每次还都是一句话也说不到点上，句句都是南辕北辙的爆典，屁股代替大脑，键盘代替思考了属于是

@w568w 即使在这种情况下也更应该使用 expect 而不是 unwrap 就是（

其实就像 guanlan 说的 unwrap 不是问题 而是没有容错机制 这是一个流程的问题不是代码的问题 就算没有最后还会 oom 的

@billbur
> 暴露的方式只有杀死进程这一种办法吗
只回应一下这一句。暴露的方式当然不只是只有杀死进程这一种，甚至可以说杀死进程本身都不能算啥暴露的方式（因为还得依赖监控啥的发现进程意外死亡了）。但是，恢复的方式只有重启这一种。尽快杀死自己让 supervisor 拉起新的才是快速恢复整体服务的方式。