有没有强迫症所有 err 必须处理的？

[voidmnwzp]

代码堆多了就不想处理，但看着满屏的警告就难受，处理了又是满屏的 if err 更难受了

[codehz]

你这所谓处理，问题也不小啊
截图中第一个，输出 err 之后，又输出 ok ？

[kkeep]

哈哈，if err != nil 要记得 return

[kkeep]

HTTPHandler 里面一般要把 err 转换成 json 返回

[voidmnwzp]

@codehz 这是我刚写完的代码 还没 review 就不用纠结了吧。。。

[Vegetable]

不知道你能决定的尺度有多大，至少你这个两个 handler 里应该是 reader->bordcast/push 的操作在设计上就不够优雅，导致代码写起来多余的东西很多。包括你用比较底层的 http 而不是封装过的框架，也产生了很多噪声。

还有一些提升空间，但是总体来说 go 的代码就是这样的，忍着吧

[statumer]

建议学习 option monad
出现错误应该往上抛并处理现场，大多数时候并不存在需要当场处理错误的情况。

[Nitroethane]

单纯交流讨论下 op 的代码，以下是我的看法：1 ）少用或避免使用 ioutil.ReadAll() 函数； 2 ） 33 行 byte slice 转 string 有性能开销，应该考虑将 httpPush.Adapter.Broadcast() 方法的参数改为 byte slice 并修改相关代码； 3 ） 48 行 json 反序列化时用 json.Decoder 更好； 4 ）状态码用 http package 中定义的常量；

[iseki]

看看，这就是没有异常机制后，好多 Go 用户说的 [优雅的错误处理] （暴论
------------------
个人的习惯是，除非理由很充分，否则永远不要用 _ 忽略错误。其次已经 err 的就不要 OK 了，大部分 err 都是现场无法处理的，往上抛，视情况决定要不要 wrap 一下加点信息，否则出了问题没法查。除非理由充分，否则永远不要 err 了还按正常流程返回结果，否则大概率会出了问题都不知道。

[Gota]

几周前刚看过一篇博客谈为什么 Go 默认的 HttpHandler 不适合直接拿来用，其中一个原因就是错误处理后容易忘返回。https://preslav.me/2022/08/09/i-dont-like-golang-default-http-handlers/

建议还是找个轻量级的 HTTP 框架，毕竟中间件、路由之类的最后还是会用到的。

[tianyou666shen]

复制黏贴 if err != nil
要不哪里报错找不到提示 真的要 g

另外你感觉 err 处理里面的重复代码多,可以进行分层
controller: 处理参数,转发到 model 或者 handler 的方法,根据是否 err 输出响应
model/handler:接收参数,有错就 return err,让上一层处理 code,msg 等返回的具体内容

这样可以减少很多直接 err!=nil 后,设置响应 code 的代码

[ClarkAbe]

io/ioutil 这个 package 已经标记弃用了.......

[sxfscool]

可以保证不会 err 的才忽略

[zmqiang]

由几次痛苦的 debug 经历都是来自随意忽略 err 或者是输出不明所以的日志，导致 debug 的过程中只能一行一行代码的过，没法很快发现问题。对于多人维护的系统来说，速错是一个很好的选择。

[Trim21]

最起码在 http.Handler 外面再包一层，加个统一的错误处理统一处理 error 的，然后写 API 的时候遇到 error 就可以直接返回 /包一下对应的 http code 再返回。标准库那个实在是难用。

[fregie]

认真处理每个错误才是最优雅的,也最好读的.只是写的时候比较难受

[ruanimal]

@statumer golang 这个咋搞 option monad

[junmoxiao]

如果是用到了外部资源的肯定要处理，用不到外部资源的忽略了无所谓

[cloverstd]

只要你有 IO 或者有 syscall ，都可能出现 error 的，写代码本来就是在处理各种异常情况，只看你忽略了错误对你业务有没有影响，忽略错误也是一种处理异常的方式

[akira]

这么写。。10 行业务代码怕不是要带上 30 行的 错误处理了

[voidmnwzp]

@ClarkAbe 有什么代替的吗