欢迎光临
我们一直在努力

To panic or not to panic

大家都知道 Golang 推荐的错误处理的方式是使用 error,这主要得益于 Golang 方法可以返回多个值,我们可以很自然的用最后一个值来表示是否有错误,这一点是其它很多编程语言所不具备的,不过这多少让那些习惯了 exception 的程序员无所适从,虽然 Golang 没有 exception,但是实际上可以通过 panic/recover 来模拟出类似的效果,于是很多 Gopher 在错误处理的时候开始倾向于直接 panic。

 

为什么会有人喜欢使用 panic 来处理错误呢?我们以流行框架 Gin 为例来说明:

package main

import (
	"errors"
	"log"
	"net/http"

	"github.com/gin-gonic/gin"
)

func recovery() gin.HandlerFunc {
	return func(c *gin.Context) {
		c.Next()

		if err := c.Errors.Last(); err != nil {
			c.String(http.StatusInternalServerError, err.Error())
		}
	}
}

func main() {
	r := gin.Default()
	r.Use(recovery())

	r.GET("/", func(c *gin.Context) {
		if c.Query("foo") != "" {
			err := errors.New("foo error")

			c.Error(err)
			return
		}

		if c.Query("bar") != "" {
			err := errors.New("bar error")

			c.Error(err)
			return
		}

		c.String(http.StatusOK, "test")
	})

	r.Run(":8080")
}

在 Gin 的用法中,当出错的时候,应该先调用 c.Error 方法来设置 error,如果是在中间件里,那么应该调用 c.AbortWithError 方法,最后还要记得调用 return 返回,后续可以在中间件中通过判断 c.Errors 来决定如何渲染状态码和错误信息。很多人会觉得先 c.Error 再 return 的操作太麻烦,于是就出现了直接 panic 的做法:

package main

import (
	"fmt"
	"net/http"

	"github.com/gin-gonic/gin"
)

func recovery() gin.HandlerFunc {
	return func(c *gin.Context) {
		defer func() {
			if err := recover(); err != nil {
				c.String(http.StatusInternalServerError, fmt.Sprint(err))
			}
		}()

		c.Next()
	}
}

func main() {
	r := gin.Default()
	r.Use(recovery())

	r.GET("/", func(c *gin.Context) {
		if c.Query("foo") != "" {
			panic("foo error")
		}

		if c.Query("bar") != "" {
			panic("bar error")
		}

		c.String(http.StatusOK, "test")
	})

	r.Run(":8080")
}

也就是说,当出错的时候,直接 panic 抛出异常,然后在中间件里通过 recover 里捕获异常,进而决定如何渲染错误信息,业务逻辑代码会更简洁明了。

如此说来,在 Golang 错误处理的时候,到底是应该使用 error 还是 panic 呢?之所有会有这样的疑问,很大程度上是因为我们混淆了错误和异常的区别:一个例子,当操作一个文件但是文件却不存在的时候,应该使用 error 而不是 panic,因为文件不存在可能在很多情况下新建一个就可以了,此时有药可救;另一个例子,当除数是零的时候,应该使用 panic 而不是 error,因为除数为零在数学上无意义,此时无药可救。

顺着这个思路,比如说在一个 MVC 架构的 Web 应用里,如果我们想在 controller 里报错,那么最终一般是展示一个定制化的错误页面,此时看上去属于无药可救的范畴,如此说来即便使用 panic 似乎也无可厚非,不过如果是在 model 之类可复用的组件中报错的话,除非真的真的无药可救,否则应该尽可能使用 error,毕竟你不可能指望别人在复用组件的时候还搭配着 recover 兜底。

此外,一旦在错误处理的时候滥用 panic,那么很可能会导致你忽略真正的 panic,比如当你的 Web 应用存在一个偶发崩溃问题的时候,而你却只是使用 panic/recover 渲染了一个错误页面,那么你很可能就错失这个问题了,当然,你可以在 recover 里记录日志信息,不过当你滥用 panic 的时候,即便记录日志信息,也会存在很多噪音,结局你很可能依然会错失真正有用的信息。问题的症结就在于混淆了错误和异常。

实际上,针对此类问题,Gin 作者有过相关的论述:Abort vs panic,Golang 官方博客中的文章也值得多读几遍:Error handling and GoErrors are values

综上所述,我们推荐 error 为主,panic 为辅。如果一定要 panic,最好是在 init 的时候 panic,毕竟一运行就看到挂掉比较容易发现并处理,对待 panic,务必要克制,它就像罂粟花,看似绚烂多彩,却隐藏着罪恶的果实,合理使用的话,有其自身价值,但千万别上瘾。

赞(1) 打赏
转载请注明来源:IT技术资讯 » To panic or not to panic

评论 抢沙发

评论前必须登录!

 

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏