分析Go错误处理优化go recover机制缺陷
目录
- 引言
- 语法说明
- 新提案
- 讨论
- 总结
引言
Go 的错误处理一直是表现最突出的一块地方，许许多多的同学都提出了各种提案，例如：引入 try-catch、用 panic 代替 if err != nil、引入新的关键字等。但这些都被一一驳回了。
不过社区依然还没放弃，周末看到有一个新的提案《proposal: runtime: add parameters to recover to only return specific types》挺有意思。
语法说明
Go 的 panic、recover、defer 的基本使用方式。如下代码：
package main
import "fmt"
func mayPanic() {
panic("a problem")
}
func main() {
defer func() {
if r := recover(); r != nil {
fmt.Println("Recovered. Error:\n", r)
}
}()
mayPanic()
fmt.Println("After mayPanic()")
}
输出结果：
Recovered. Error:
a problem
新提案
由于有 Go1 兼容性保障，新提案是在原有的 recover 函数上动小手术。希望可以现在运行时的 recover 中加入参数，仅支持返回特定的类型。
函数签名：
recover(except ...interface{})
案例代码：
defer func(){
if err := recover(&MyError{}, &HelloError{}); err != nil {
switch e := err.(type) {
case *MyError:
fmt.Println(e)
case *HelloError:
fmt.Println(e)
}
}
}
上面代码中，recover 函数只支持传入 MyError 和 HelloError 的指针类型。再在处理逻辑中根据所传入的错误类型，进行断言分类，实际上去做不同的逻辑处理。
重点就是限定 recover 入参类型。
讨论
有些小伙伴可能发现了，对比看看 PHP 的 try-catch 的用法，与前面的提案代码是不是有好几分神似呢？
如下代码：
try {
...
}
catch (Exception $e) {
echo $e->getMessage();
}
catch (InvalidArgumentException $e) {
echo $e->getMessage();
}
catch (BarException $ex)
{
echo $e->getMessage();
}
catch (FooException $ex)
{
echo $e->getMessage();
}
本质上这个新的提案是想在不破坏 Go1 兼容性的情况下，在 Go 中实现 try-catch 的方式。
社区在交流时，也发现了用户在现有机制下可以自主实现 Go 的类 try-catch 的模式。
如下代码：
func Recover(expect ...interface{}) interface{} {
if err := recover(); err != nil {
if len(expect) == 0 {
return err
}
rv1 := reflect.Indirect(reflect.ValueOf(err))
for _, e := range expect {
rv2 := reflect.Indirect(reflect.ValueOf(e))
if rv1.Type() == rv2.Type() {
return err
}
}
panic(err)
}
return nil
}
这个自制方法的问题是每次 Recover panic 都会将堆栈深度增加 2。因此还是寄希望于 Go 官方能够在运行时支持。
在 Go 标准库的用途对比上，也有产生一定的作用，其涉及到的代码基本为：
总结
这个提案本质上是希望通过在 recover 函数中增加入参控制，再配合内部逻辑实现类似 Go 版本的 try-catch 的错误处理机制模型，且实际在 Go 标准库中有复用的空间。
但现阶段该提案也是赞同和反对参半，也有人认为可以用户自己实现，那就没必要加大复杂度，去做这个收益不够大的实现。
你觉得这能补全 Go 错误处理的一些机制缺陷吗？
以上就是分析Go错误处理优化go recover机制缺陷的详细内容，更多关于go recover错误处理的资料请关注我们其它相关文章！
相关推荐
-
go语言的panic和recover函数用法实例
Golang 有2个内置的函数 panic() 和 recover(),用以报告和捕获运行时发生的程序错误,与 error 不同,panic-recover 一般用在函数内部.一定要注意不要滥用 panic-recover,可能会导致性能问题,我一般只在未知输入和不可靠请求时使用. golang 的错误处理流程:当一个函数在执行过程中出现了异常或遇到 panic(),正常语句就会立即终止,然后执行 defer 语句,再报告异常信息,最后退出 goroutine.如果在 defer 中使用了 re
-
Go程序员踩过的defer坑错误处理
目录 前言 一.简单的例子 二.一定不要在 for 循环中使用 defer 语句 三.定义函数时就不要使用命名返回值 四.defer 表达式的函数如果在 panic 后面,则这个函数无法被执行. 五.执行顺序 五.捕获异常执行顺序 六.函数执行顺序 七.外部函数捕获异常执行顺序 八.recover 的返回值问题 前言 先声明:我被坑过. 之前写 Go 专栏时,写过一篇文章:Go 专栏|错误处理:defer,panic 和 recover.有小伙伴留言说:道理都懂,但还是不知道怎么用,而且还总出现
-
golang 中 recover()的使用方法
Recover 是一个Go语言的内建函数,可以让进入宕机流程中的 goroutine 恢复过来,recover 仅在延迟函数 defer 中有效,在正常的执行过程中,调用 recover 会返回 nil 并且没有其他任何效果,如果当前的 goroutine 陷入恐慌,调用 recover 可以捕获到 panic 的输入值,并且恢复正常的执行.通常来说,不应该对进入 panic 宕机的程序做任何处理,但有时,需要我们可以从宕机中恢复,至少我们可以在程序崩溃前,做一些操作,举个例子,当 web 服务
-
GO语言异常处理机制panic和recover分析
本文实例分析了GO语言异常处理机制panic和recover.分享给大家供大家参考.具体如下: Golang 有2个内置的函数 panic() 和 recover(),用以报告和捕获运行时发生的程序错误,与 error 不同,panic-recover 一般用在函数内部.一定要注意不要滥用 panic-recover,可能会导致性能问题,我一般只在未知输入和不可靠请求时使用. golang 的错误处理流程:当一个函数在执行过程中出现了异常或遇到 panic(),正常语句就会立即终止,然后执行 d
-
Golang 错误捕获Panic与Recover的使用
目录 一.Golang 错误是什么? 二.错误校验 1.方法 2.判断错误 三.错误捕获 1.方法 2.defer 的使用 总结 一.Golang 错误是什么? 对于Go语言(Golang)的错误是通过返回值的方式,来强迫调用者对错误进行处理,要么你通过 _ 忽略,要么你处理.对于这种设计方式,我们通常需要会写大量的 if err != nil 判断.我们可以通过方法来做到校验. 这类代码非常的多,尽管工程中 error 大部分都是nil,也就是没有任何错误,但是非nil的时候,就意味着错误就出
-
Go 错误处理实践总结示例
目录 前言 Go 错误处理机制 Go 内置 errors Error 与 Exception Go 错误处理最佳实践 panic error 总结 前言 最近在对极客时间毛剑老师的 Go 进阶训练营进行重温和学习汇总,这是一门比较偏向于工程化以及原理层面的的课程,涵盖的知识点非常多,因此决定开一个系列来进行记录,也便于自己总结查阅. Go 错误处理机制 Go 内置 errors Go 语言中的 error 就是普通的一个接口,表示值 // http://golang.org/pkg/builti
-
分析Go错误处理优化go recover机制缺陷
目录 引言 语法说明 新提案 讨论 总结 引言 Go 的错误处理一直是表现最突出的一块地方,许许多多的同学都提出了各种提案,例如:引入 try-catch.用 panic 代替 if err != nil.引入新的关键字等.但这些都被一一驳回了. 不过社区依然还没放弃,周末看到有一个新的提案<proposal: runtime: add parameters to recover to only return specific types>挺有意思. 语法说明 Go 的 panic.recov
-
详细分析c# 客户端内存优化
背景概述 C# 开发客户端系统的时候,.net 框架本身就比较消耗内存资源,特别是xp 这种老爷机内存配置不是很高的电脑上运行,所以就需要进行内存上的优化,才能流畅的在哪些低端电脑上运行. 想要对C# 开发的客户端内存优化需要了解以下几个概念. 虚拟内存 这里引用百度百科的概念:虚拟内存是计算机系统内存管理的一种技术.它使得应用程序认为它拥有连续的可用的内存(一个连续完整的地址空间),而实际上,它通常是被分隔成多个物理内存碎片,还有部分暂时存储在外部磁盘存储器上,在需要时进行数据交换.目前,大多
-
NodeJS读取分析Nginx错误日志的方法
网上很少看到有用NodeJS运维系列文章,后续我会更新一些NodeJS运维相关的内容又或者说让我们更加的深入了解一些服务器的知识以及自动化运维方面的基础知识 为什么要做错误日志分析,因为网上这方面的工具不多我找到一个goaccess但是都是分析成功日志以及用户访问趋势,找了半天没找着自己想要的索性就自己利用Node造一个 错误日志分析 首先我们要读取Nginx日志,我们可以看到Nginx的错误日志格式一般都是这样子,需要注意的是Nginx的错误日志格式是差不多的因为无法设置日志格式只能设置日志错
-
实例分析ORACLE数据库性能优化
ORACLE数据库的优化方式和MYSQL等很大的区别,今天通过一个ORACLE数据库实例从表格.数据等各个方便分析了如何进行ORACLE数据库的优化. tsfree.sql视图 这个sql语句迅速的对每一个表空间中的空间总量与每一个表空间中可用的空间的总量进行比较 表空间是数据库的逻辑划分,一个表空间只能属于一个数据库.所有的数据库对象都存放在指定的表空间中.但主要存放的是表, 所以称作表空间. SELECT FS.TABLESPACE_NAME "Talbspace", (DF.TO
-
从源代码分析Android Universal ImageLoader的缓存处理机制
通过本文带大家一起看过UIL这个国内外大牛都追捧的图片缓存类库的缓存处理机制.看了UIL中的缓存实现,才发现其实这个东西不难,没有太多的进程调度,没有各种内存读取控制机制.没有各种异常处理.反正UIL中不单代码写的简单,连处理都简单.但是这个类库这么好用,又有这么多人用,那么非常有必要看看他是怎么实现的.先了解UIL中缓存流程的原理图. 原理示意图 主体有三个,分别是UI,缓存模块和数据源(网络).它们之间的关系如下: ① UI:请求数据,使用唯一的Key值索引Memory Cache中的Bit
-
Javascript中toFixed计算错误(依赖银行家舍入法的缺陷)解决方法
前言 在公司项目中涉及到一个有大量浮点数价格计算的模块,从而引发了我一系列的思考: 计算机二进制环境下浮点数的计算精度缺失问题; console.log(.1+.2); 0.30000000000000004 为了解决上述问题,使用了toFixed方法却出现了浮点数小数位以5结尾的四舍五入错误问题; var num = 0.045; console.log(num.toFixed(2)); 0.04 以此为起点,引发了我关于toFixed的一系列探索,终于找到了一些有用的信息,toFixed使用
-
Android APP性能优化分析
本文通过Android APP性能优化的四个方面做了详细分析,并对原理和重点做了详细解释,以下是全部内容: 说到 Android 系统手机,大部分人的印象是用了一段时间就变得有点卡顿,有些程序在运行期间莫名其妙的出现崩溃,打开系统文件夹一看,发现多了很多文件,然后用手机管家 APP 不断地进行清理优化 ,才感觉运行速度稍微提高了点,就算手机在各种性能跑分软件面前分数遥遥领先,还是感觉无论有多大的内存空间都远远不够用.相信每个使用 Android 系统的用户都有过以上类似经历,确实,Android
-
Golang中重复错误处理的优化方法
Golang 错误处理最让人头疼的问题就是代码里充斥着「if err != nil」,它们破坏了代码的可读性,本文收集了几个例子,让大家明白如何优化此类问题. 让我们看看 Errors are values中提到的一个 io.Writer 例子: _, err = fd.Write(p0[a:b]) if err != nil { return err } _, err = fd.Write(p1[c:d]) if err != nil { return err } _, err = fd.Wr
-
SpringBoot2.1.4中的错误处理机制
目录 SpringBoot 2.1.4 错误处理机制 SpringBoot错误机制原理 SpringBoot 2.1.3 错误处理机制 引用的问题做个标记 错误处理机制 SpringBoot 2.1.4 错误处理机制 springboot的自动配置中帮我们配置了相关的错误处理组件,例如访问一个不存在的页面,就会出现下面的错误页面,上面也会显示相应的信息 在Postman软件中模拟移动端访问,会获取如下响应的json数据: 可以发现springboot的错误处理机制很好的适应了不同客户端访问,浏览