rust 里 unwrap 用起来真方便,但如果不用 unwrap

[v2defy]

如果不用 unwrap, 就需要 if let 判断是不是个正常值, 感觉和 go 的 if err != nil 区别不大了就.

虽然可以使用 ? 把错误抛往上层, 但一直往上抛也不是办法, 总要找个恰当的时机把它判断处理了.

unwrap 真的方便, 但是会导致程序退出, 你们写 rust 的时候什么使用用 unwrap, 什么时候不用呢?

[fengjianxinghun]

这么多东西可以处理。。。
?
ok_or
unwrap_or_*
and_then

[BBCCBB]

unwrap 只有在确定没问题的时候才能用吧.
不想每个都处理, 就用?抛到外面, 总有个地方要处理..

但 Error 类型不同的时候也比较麻烦, 虽然可以通过 From 来处理, 但还是麻烦. 优点就是性能好, 比 go 的 if err!=nil 高明些..

[BBCCBB]

要说方便, 还得是 try catch.

[alexsunxl]

.map_err()?
map_err 关键错误加点 log ，处理还是抛给上层。我是专门有一层有一块专门处理 error 的，还有分发逻辑的 dispatch handler 之类的概念。
测试代码就直接抛到 main 。

[Kasumi20]

如果 try catch 方便的话，Kotlin 为什么不保留

[learningman]

@Kasumi20 #5 kt 有 try catch 啊

[Jwyt]

这么多组合器你都没用过？
map_or*
ok_or*
unwrap_or*
and*
还有 matches!宏，比 try-catch 方便多了

[LaTero]

能确保不会忘记，用一个'?'就能向上 propagate 很方便，而且一般都是用楼上说的 ok_or*之类的吧，需要 if let 的情况很少。
@BBCCBB 我就很讨厌 try catch ，经常忘记，而且长。有的语言看字典里有没有这个键都要 try catch 搞个 5 行出来。

[TWorldIsNButThis]

根据业务，如果无法处理就爆掉啊
比如业务上一定会有的数据但是数据库里数据缺失了
不 panic 还能干嘛

[BBCCBB]

@LaTero c#这种不是强制性捕获异常的会忘记, 但强制性捕获的就不会. k in dict 这个你说的是哪个语言?

[LaTero]

@BBCCBB 好像是 python （我可以肯定是个动态语言）的一个解析某种格式的文件的库。我记得自己之前写的一个小脚本，只能自己写个函数 try catch 判断有没有这个 key 。如果是像 rust 这样就方便多了。

[LaTero]

@BBCCBB 好像是切换代理的脚本，那个库是解析机场订阅的

[v2defy]

@Jwyt 请问这些你们是怎样从哪学到的呢? 翻文档吗? the book 里没讲这些

[BBCCBB]

@LaTero 哈哈, 可能是对 python 的写法不熟悉, 他有 key in dict 的判断方法,

[LaTero]

@BBCCBB 它应该不是 python 的 dict ，是一个自定义的类。不过也是很久以前写的了，可能确实是我刚学太菜。

[kujio]

kotlin 写法，，受 rust 启发。

[Jwyt]

@v2defy 我也是后来自己搜的；在 option 和 result 后面打上点，vscode 给出很多方法提示，之后自己搜才知道这些

[lmshl]

Either(Result) Monad 的最佳用法是 Railway Oriented Programming
https://fsharpforfunandprofit.com/rop/
理论基础都在函数式编程里😏

[steins2628]

默默学习

[DeWjjj]

一律都外部处理，函数就是个黑箱。
哪有在黑箱里面做判断的，那就变成两层黑箱了。
而且拿到数据，或者报错处理肯定都建议在函数体外做。一个成熟的函数肯定要重复利用，就会导致 result 类枚举里面夹的也是多种类型。

[seansong]

unwrap 是你接触的第一个异常处理方式

除非你确认结果一定不会异常，或者这个异常完全没有捕获并恢复的必要，可以考虑用 unwrap

if let 相当于只是 match 的语法糖，大部分时候，还是得用 match 来处理

[skies457]

anyhow 很好用
https://docs.rs/anyhow/latest/anyhow/

[andyJado]

切肤体会最贴心的是 expect

程序读起来像是在许愿.