我们的项目用的iris框架, 在接口里面开启go程后如果go程 panic 了, 则整个服务都会挂掉, 能不能写一个全局的 recover来监听go程的 panic
看不懂中文? 已经不让你回复了为啥还这么厚脸皮呢?
我求你回复了?可惜这个论坛没有拉黑功能,不然那些不请自来讨人厌的家伙真的是可以用这种方法屏蔽掉。
你可以自由回复楼主,别在回复本人了!你牛逼行了吧?请你走开!
这是本人最后一次提示不要回复了,本人没有求你回复回答本人的问题。
redis或者数据库连接不上会panic,
这种情况需要recover来输出这种错误?或者这种错误还要继续运行进行所谓的什么都不能做的服务?
而不是立刻停止程序马上检查相关的设施和网络,给用户一个临时性的维护提示,服务器转移或者集群LB,
这种错误是无法继续运行的打印log有P用?
程序panic直接会报错在控制台或者系统日志里。甚至最简单的方式存在一个启动时就能打印到指定的转向日志文件中。
用得着专门用recover打印?
程序panic崩溃了退出,各种资源是立即由操作系统强行释放的,用 recover能释放什么?释放所谓的局部资源?释放了程序的行为就正常了?
golang wiki 只是描述它的行为是类似try catch来改变程序走向让崩溃的程序找一个出口而已,这到了某些人眼里就成了可以用来打印log释放资源!
出了panic错误, 你可以通过recover有机会处理一下,如果你不处理,go自己就会停掉程序输出panic信息。就这么点区别。
这一点和C语言longjump类似。
不管你是不是用recover处理了,结果都没有什么改变。程序还是崩溃了。下次同样的执行路线依然会崩溃不会自行恢复。除非你找到确切的问题点修复掉,不管是测试不够导致的软件质量问题的还是硬件故障导致的。
而且,golang的panic比exception严重多了,对应的级别更高的error, 就像java的OOM,
而golang的error针对的才是exception, 不需要改变程序的走向,只需要对严重级别较低的错误进行判断和处理即可。
如果可以把panic等同于try catch 随便乱用来打印什么log, 释放什么资源,那么golang的defer 和 error就成了一个多余的笑话。
因为如果想像trycatch一样使用改变程序行为直接一个panic中断程序然后跳到recover处理,程序里到处都是这个,想想就呵呵了!!!
panic大多是硬件问题导致的,比如内存不够,网络不通,被零除等等。这些当然不能赖测试,官方文档说了是辅助报告调试用的,
也就是说这个东西是防备万一出现的隐形坑,辅助报告可以让你在这里多说一些废话帮助查找问题原因, 但是大多数情况下,panic自身的报告信息就足够详细和定位问题了,除非一些不明显的内存溢出问题。不管什么目的,这里打印什么log和释放资源都毫无意义,只是为了满足某些人离开try catch习惯就没办法写代码而设置的一个机制。
#26
更多评论
<a href="/user/polaris" title="@polaris">@polaris</a> 如果不考虑go程的话可以监听, 但是go程里面不知道咋监听...
#2