关于 Let it crash 和错误处理

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

The Go Programming Language

› http://golang.org/

› Go Playground

Go Projects

› Revel Web Framework

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

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

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

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

crash

错误

监控

9 条回复 • 2025-01-02 10:32:30 +08:00

zjsxwc

2 天前 via Android

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

kneo

2 天前

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

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

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

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

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

Immortal

2 天前

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

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

Immortal

2 天前

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