@user8341 如果 receiver 是 T，那调用的时候，就是复制再传参的。所有参数都是复制再传递的。不要以为用对象调用方法，就不会复制。T 和*T 两种 receiver 是有区别的

@Nugine0 继续更新你转移话题的历史：
“go 稍微给点语法糖都不会被喷 if err != nil，但还是坚持，估计以后也会一直被喷。”
告诉你可以用函数替代了
“写函数替代 if err != nil 不能改变控制流，用 panic/recover 又与你之前的言论矛盾，我很好奇你是怎么写的。”
告诉你怎么写了
“用 panic/recover 来处理 error 就是一种混淆的做法，不然为什么不设计成 try/catch ？”
告诉你官方也推荐这么用了
“能用不代表它就是好的。”
呵呵，连万能句式都出来了
“语法糖不等于函数”
明明你不想写 if err != nil，那现有的机制就能解决，怎么变成非语法糖不可了？
这就是明显的转移话题，试图把话题从“if err != nil”，转移到“语法糖”
“把 if err != nil 换成 check(err)，还是填一发打一枪。写个函数就不是“判断错误”了？真搞笑。”
函数写给你了，怎么改变控制流也告诉你了，这里的 panic 不会跨越包边界也告诉你了，现在忽然又转移话题，用函数判断错误就不行了？？

看看你前面的论点，还有多少站得住脚吧。
也难怪你不停转移话题，不就是想让人忘记你前面说过的话嘛，让人忘记你的错误嘛。
所以我就要复制出来，免得跑题了。

我写的 ReadFile，很明显就有一个 error 返回值，我说用 panic/recover 做错误处理，从来就没有说要抛出 panic 给调用者，你以为用 panic/recover 处理错误，就等于抛 panic 给调用者，这是你的错误理解。
你以为是函数实现者用 panic 抛出，调用者用 recover 接住？
不是的，panic/recover，都是函数实现者一侧调用的，上面的 check 里用了 panic，catch 里用了 recover，这一对是在同一个函数里用的，recover 是用来将 panic 抛出的错误，赋值给 error 返回值用的。
根本不是你理解的那样，将 panic 抛给调用者。

这都还不明白的话，那我也确实没法再说什么，你水平太低。

@Nugine0 “跨越库的边界时，还得老老实实地判断错误”，大错特错。
说了半天，你都不知道别人怎么用的。
例如使用标准库来写一个复制文件内容的函数，可以这样写：
func CopyFile(path string, w io.Writer) (err error) {
defer catch(&err)
f, err := os.Open(path)
check(err)
defer f.Close()
_, err := io.Copy(w, f)
check(err)
return nil
}
有“if err != nil”吗？没有。就是这么简单的一件事情。

这种处理错误的方式，本来就没有说错误不是用 error 返回，也不会将抛出 panic 作为接口的一部分。
你扯什么 try/catch ？你该不会以为说用 panic/recover 处理错误，就等于不要 error 返回值吧？
我看你根本对于“现有机制”没有足够的了解。

阻止你使用这种方式来处理错误的，只是你的偏见，而不是什么共识。
你根本不用管别的库怎么处理错误，因为大家都是用 error 返回的。
在你的代码里，你喜欢写 if err != nil 就写，不喜欢写就可以用上面的方式，根本不涉及跨库。

“go 稍微给点语法糖都不会被喷 if err != nil，但还是坚持，估计以后也会一直被喷。”
喷子永远有喷的理由，一个理由站不住脚了，就找另一个。
你看喷包管理的不见了，喷没有泛型的也不见了。
当然，也有角度清奇的，“内卷工具”，佩服，这都想得出。

“以前还有 go 不需要泛型的说法”，这也是由来已久的偏见和误解，官方的态度从来都不是不需要，而是没发现好的实现方式。直到现在有了泛型的提案，对于具体的实现方式，也还没有确定，还在讨论： https://groups.google.com/g/golang-dev/c/OcW0ATRS4oM/m/5-kMv9i-BQAJ

可能以后量子计算机可以由公钥计算出私钥

如果不懂基本概念，还是慎重操作，先备份好文件，做好全部资料丢失的准备
不是说笑，见过几次因为不懂分区，不懂文件系统，错误操作，导致资料丢失，没法恢复的惨剧

@Nugine0 那我就继续更新呗：
“go 稍微给点语法糖都不会被喷 if err != nil，但还是坚持，估计以后也会一直被喷。”
告诉你可以用函数替代了
“写函数替代 if err != nil 不能改变控制流，用 panic/recover 又与你之前的言论矛盾，我很好奇你是怎么写的。”
告诉你怎么写了
“用 panic/recover 来处理 error 就是一种混淆的做法，不然为什么不设计成 try/catch ？”
告诉你官方也推荐这么用了
“能用不代表它就是好的。”
呵呵，连万能句式都出来了
“语法糖不等于函数”
明明你不想写 if err != nil，那现有的机制就能解决，怎么变成非语法糖不可了？
这就是明显的转移话题，试图把话题从“if err != nil”，转移到“语法糖”

用 panic / recover 可不是我提出来的，是官方标准库，官方博客，官方 FAQ 里都有的。
别试图偷换概念。

方法本来就是一个函数，这个函数的第一个参数就是 receiver，所以可以用这个方式调用

@plko345 把 expect 、unwrap 这些可能 panic 的方法都删除吧

@Nugine0 这就很搞笑了，你帮我贴出了一篇支持我的观点的文章
你贴出的 effective go 里明确写了：
“With our recovery pattern in place, the do function (and anything it calls) can get out of any bad situation cleanly by calling panic. We can use that idea to simplify error handling in complex software. ”
不用 panic / recover 处理错误，你就在那里喷 if err != nil 繁琐
用了 panic / recover 处理错误，你就在那里喷违背设计意图
你就没想过 panic / recover 本来就包含了这个意图？
怎么你都能喷
你就是想喷而已

看看你转移了多少次话题吧：
“go 稍微给点语法糖都不会被喷 if err != nil，但还是坚持，估计以后也会一直被喷。”
告诉你可以用函数替代了
“写函数替代 if err != nil 不能改变控制流，用 panic/recover 又与你之前的言论矛盾，我很好奇你是怎么写的。”
告诉你怎么写了
“用 panic/recover 来处理 error 就是一种混淆的做法，不然为什么不设计成 try/catch ？”
告诉你官方也推荐这么用了
“能用不代表它就是好的。”
呵呵，连万能句式都出来了

@Nugine0 你想论证的“要么成功要么失败”，是假命题。因为实际情况有四种或者以上，不是只有两种，你的论证不成立。
请不要试图篡改事实，事实是别人说了 10+10+10+12 = 42，是你自己跳出来说 21 + 21 = 42 才是“真正写法”，是你自己首先否定 10+10+10+12 = 42，而我没有否定任何一种写法。
不要再给我加戏，再说一次。

Dave Cheney 是语言设计者吗？他自己的观点，就能当成设计意图？

看看 go 官方博客里怎么说的吧： https://blog.golang.org/defer-panic-and-recover

“For a real-world example of panic and recover, see the json package from the Go standard library. It encodes an interface with a set of recursive functions. If an error occurs when traversing the value, panic is called to unwind the stack to the top-level function call, which recovers from the panic and returns an appropriate error value (see the 'error' and 'marshal' methods of the encodeState type in encode.go).”

滥用？官方博客直接告诉你可以这样用了。

不越过库边界和这有什么关系？？说的是替代 if err != nil 这种写法，而不是替代 error 。
承认 go 开发者可以不用写 if err != nil，有那么难吗？
更不用说很多人根本就不觉得写 if err != nil 有什么问题，就你这种根本就不用 go 的人在瞎逼逼

https://wccftech.com/a14x-bionic-performance-equal-to-8-core-16-inch-macbook-pro/

According to These Numbers, the A14X Bionic Is Said to Be Equal in Performance to a 16-inch MacBook Pro Running an Intel Core i9-9980HK

5nm 的处理器，和 14nm 的比，有啥好比的，制程都差了两代了，单靠制程红利都应该超过

@Nugine0 最开始的四个分支的 match，就是用来说明 rust 可以怎样处理各种情况的，你说它错，又提出用 ? 才是“真正写法”，或者用两个 match 分支，你是对原先多分支 match 的完全否定，甚至说我“被钓鱼”。然而我已经找出了实际的用例给你看了，别人并不是用 ? 运算符，也不是只用两个分支的 match 来处理，完完全全就是像最开始另一位网友给出的示意代码那样，匹配 Ok 的两种情况和 Err 的两种情况。

你要是不记得自己说过什么，我给你复制出来：
“前面人给的 rust 代码是错的，你却拿这个举例，算不算被钓鱼？”
“ rust 的真正写法是 read(&mut buf)?，或者用两个分支的 match 分别处理成功和失败。成功分支中有可能是已读完的情况。”

你要是非认为前面人给的 rust 代码是错的，那没影响，我可以改用前面 github 上的三个现成的实例。
麻烦拿你“真正的写法”，或者“两个分支的 match”，去给这些项目提 pull request 。别人接受了，你这段话，才是对的。

我看你根本就是不懂 go 的，又说你好奇我怎样用 panic / recover 处理错误，结果我给出代码了，你对于关键的问题，完全没了解。
https://github.com/golang/go/blob/869c02ce1f635960bfc2f06bb52e2b4e17eaa199/src/encoding/gob/error.go#L36
这一行是关键，用 panic / recover 处理错误，只会 recover 特定类型的错误，并不会 recover 所有 panic 。
所以，如果有其他方式的 panic，那是会再次抛出的，根本不会被转化成 error 。
panic / recover 处理错误，处理的是预期中的错误，也就是不用 panic / recover 也要处理的那一类错误
而非预期的错误，因为不可能是预定义的类型，所以根本就不管，仍然是继续 panic，不会被 recover
你还不是水平低下？这么简单的事实，你自己理解错误，反而说我双标？

@Nugine0 你这个问题，就等于“豆腐花放糖就是一种混淆的做法，为什么不放盐？为什么不放卤水？”

你没发现你提出的，都是一些甜咸问题吗？

甜的就是反人类，咸的就是不反人类，诸如此类。

我当然不想理会你这种无聊的问题。

@Nugine0 得了吧，你就是那种明明做了，却非要说不是，非要不认的人。
傻子都知道你想说的是谁，你非要此地无银，“别误会，说的不是你”，真是笑死个人。
就是不肯承认自己说错了，非要诸多辩解。
你在其他帖子里怎样吹 ? 运算符，以为没有记录吗？忽然发现 ? 不能包打一切了，忽然发现别人的多个分支的 match 也是对的，就来死嘴硬，说什么编译过了才是“真正的写法”。
谁不明白你那点心思啊？
我又什么时候说过 if err != nil 好了啊？你能不能把你这毛病改改，别给别人加戏啊？
“go 稍微给点语法糖都不会被喷 if err != nil，但还是坚持”，我这不是告诉你用函数就可以替代 if err != nil 吗？倒成了我的不是了？

@Nugine0 就是用 panic / recover 啊，矛盾在哪里？？你对我那句话的理解，明显有严重偏差。

以标准库的 errors.As 为例，这个函数只返回一个 bool，对于误用的情况，全部直接 panic： https://github.com/golang/go/blob/9706f510a5e2754595d716bd64be8375997311fb/src/errors/wrap.go#L77

我那句话的意思是，有问题的程序，会直接 panic，而不需要写代码掩盖代码本身的问题。errors.As 也没有返回 error，就是基于这样的设计理念。

这和用 panic / recover 处理错误，根本毫无关系。

用 panic / recover 处理错误的方式，go 标准库里面就有： https://github.com/golang/go/blob/869c02ce1f635960bfc2f06bb52e2b4e17eaa199/src/encoding/gob/error.go#L17
当然，我用的比这个复杂一些，例如 if err != nil，是放到 error_ 里面的。

我就想问，你们这些喷 if err != nil 的人，知道这个事实吗？知道 go 可以不用 if err != nil 处理错误吗？？

“前面人给的 rust 代码是错的”
“rust 的真正写法是 read(&mut buf)?，或者用两个分支的 match 分别处理成功和失败。”
别改口，v2ex 是不能修改历史发言的，你说过什么，想表达什么意思，清清楚楚。

对着你这种明明水平不高，还满嘴“正常人思维”、“反人类”、“心智负担”、“大道至简”的人，能不火起的人，我会非常佩服他。

@Nugine0 编译不过？？示意代码还要管能不能编译？？

要看能编译的是吧？

https://github.com/cpjreynolds/rivet/blob/de560ca3f6cc3f57832e62da811f1c3fd38cc495/src/io.rs#L13

https://github.com/jonhoo/volley/blob/d115aaba24cce1c939d79594bc4f9ff5c5299fa8/servers/rust/main.rs#L55

https://github.com/isamert/scheme.rs/blob/acc8dca48c87abeaeb3e75d8790cfd516fb5a6f9/src/utils/chars.rs#L30

随便都能搜出现成的用例，你要不要去告诉他们，他们这样写是错的？真正的写法是 read(&mut buf)? ？或者 match 用两个分支才是对的，用四五个就是不对？

@Nugine0 我操，我在这个帖子里讨论了半天的错误处理，是你自己忽然扯出来什么“go 自称简单，但实际上并不简单。”。我有和谁讨论过简单不简单的问题？？？？？？？？？
你能不能不要自说自话？
语法糖个屁啊，我就是用一个函数替代 if err != nil 的。喷的都是不会的，就知道人云亦云。
有学习成本怎么了？又不是弱智，学不会还是怎么了？
你和 go 有什么深仇大恨你自己解决，你不同意楼主的说法你就直接发帖，别 @ 我，我不和你讨论这些。

@Nugine0
错的？他只不过将需要处理的情况都写成 match 分支，到你嘴里就成了错的？
read(&mut buf)? 根本没处理 Interrupted 。
用两个 match 分支处理，那分支里面的代码被你吃了？ Ok 里面需要处理 0 和非零的情况，Err 里面又有需要特别处理 Interrupted 的情况。
我可没说过 go 简单，谁和你说 go 简单，你就和他去辩论，别找我，别自己竖个靶子就来打。
事实？你的观点充满了偏见，拿自己的定义当普遍真理，和你讨论，纯粹就是 flamewar，毫无价值可言。