关于 Let it crash 和错误处理

[dwu8555]

因为早期学习过 Erlang ，所以对 Let it crash 深为赞同。

我完全赞成“Let it crash （让它崩溃）”，因为那样它会迫使你修复或处理极端情况。优雅地处理错误（ gracefully ）只会让事情顺利进行，即使系统中可能存在根本性错误。

而且隐藏 bug 一点也不优雅。它仍然是一个错误，你越早知道它，就越容易调试。

所以我的 go 程序里面大部分都是直接 panic ，多实例运行，配合 grafana 来监控，基本上没啥问题。

[zjsxwc]

不一样，erlang 的 actor 模型，挂了就挂了，没啥问题，系统会自动重启，php 的 fpm 也是这样挂了就挂了无所谓反正会重启，但对于普通通用语言，来说遇到一个小问题直接挂不合适，就行你操作系统里一个普通 notepad 进程挂了你直接来个蓝屏一样不合适

[kneo]

建议你贴段代码来看看。我很难想象你的“程序里大部分都是直接 panic”。

大多数情况 Panic 之后唯一能做的就是不断重启。只有在你认为出这种错是程序有 bug 的情况才能 panic ，重启之后可能问题就重现不了了——或者，你不清楚怎么处理这个问题，先 panic 再说。

而理想点的话，panic 让你发现程序 bug ，你之前预想不到怎么处理的情况，在 panic 之后你知道怎么处理，加入相应的错误处理，程序里 panic 应该会越来越少。

程序里太多 panic 可能说明你的程序应用场景比较简单，一直没测试到这些异常情况。

Panic 对程序员个人自用脚本来说当然是比较友好的，出错了再说。但是作为产品来讲，对程序架构的要求更为严格，你需要设计你的程序，保证它在崩溃之后能够快速重启，不丢失业务数据，不影响用户体验，能够记录足够多的信息便于追溯问题。对于大多数有状态的程序来说是很困难的。

[Immortal]

盲猜你指的是 Go Web 开发.
Go 的 Request 都在自己的协程内处理,所以 panic 影响的只是单次请求,又有框架兜底 recover 自然会觉得可以接受.如果是应用形的程序应该不能这么粗暴的处理了.

学习多种语言的理念和设计确实挺好的,但是我觉得不能直接代入或者钻牛角尖.还是需要更多的结合语言自身特点和最佳实践来.那个 Error 处理帖子我也看了,有很多可以学习的地方.

[Immortal]

@Immortal #3
补充下 panic 的语义
我理解的最佳实践应该是应用(程序)遇到不可恢复的错误,例如数据库连接失败/配置文件缺失/端口占用等等,导致应用已经无法正常使用才会使用 panic.而常规业务逻辑上的错误就应该用常规手段(err)来处理.

[dwu8555]

@Immortal #3 不是，我搞 crypto web3 开发

[yanyao233]

直接 panic 不合适吧，难道你做了全局 recover ？个人认为业务错误最好的处理方法还是逐层传递 err

[james122333]

工作项目中直接 crash 是挺不错
很多时候需要中断运行 逐层传递需要写太多代码 业务逻辑开发时明显不利
go 的 panic 好处就是不用逐层传递 可以使用多个 defer 也很灵活简洁

[Ipsum]

无状态的程序怎么挂都行，就怕有状态的。

[Ayanokouji]

问一下，数据库事务里边也直接 paic 吗

[1Z3KYa0qBLvei98o]

crash early