最近的评论

• 2019-09-08 12:17:43 评论了主题 求大神指教, 如何写一个全局recover,保证服务不会因为go程里面的panic整个挂掉
  -
• 2019-09-06 22:36:32 评论了主题 求大神指教, 如何写一个全局recover,保证服务不会因为go程里面的panic整个挂掉
  22楼 @focussoft 小兄弟你淡定点，你先看看我举的例子。。。 按你的方式，进程肯定宕，我举例子的场景，只是少量触发异常的请求失败，并不会服务不可用 panic不一定是对整个服务都致命的bug，我举的例子一样适用，你先冷静想想，不要带着偏激的情绪去讨论问题 另外，你说的core dump是指控制台输出吗？规范点的项目，不会依赖控制台输出重定向这种日志的。。。 最简单的方式思考：如果panic了就必须让进程退出，那recover还有存在的必要吗？那go团队提供了recover难道是go团队脑残吗^_^
• 2019-09-05 15:34:52 评论了主题 求大神指教, 如何写一个全局recover,保证服务不会因为go程里面的panic整个挂掉
  #19楼 @nothollyhigh 另外，除了启动阶段初始化依赖项，服务正常运行后，不可预料的代码bug导致的panic尽量避免，而且不建议代码里手动panic的方式处理error
• 2019-09-05 15:31:17 评论了主题 求大神指教, 如何写一个全局recover,保证服务不会因为go程里面的panic整个挂掉
  #9楼 @focussoft 各位都淡定，讨论问题没必要生气，冷静，冷静 ^_^ panic并不代表是必须代码修复的严重bug，比如web服务，单个路由接口的处理函数中，某个 if 条件下的代码可能有一个nil指针导致的panic，但是这个 if 分支可能只是少量情况，大多数请求的调用，都不会触发这个panic 这时候recover+日志可以帮助排查bug，并且线上不至于宕机 如果收到panic就应该宕机等待人工修复，那才是线上服务长时间中断，而且panic如果必须宕机，那么 recover 存在的意义是什么？而且其他语言的try catch与recover是类似的 测试阶段应该尽量覆盖代码分支，线上服务可用也是需要保障的
• 2019-09-01 18:47:24 评论了主题 多个panic，recover如何写？
  建议做统一的recover封装，类似： ```golang package main import ( "fmt" "github.com/nothollyhigh/kiss/util" ) func test() { defer util.HandlePanic() fmt.Println(111) panic("err 1") fmt.Println(222) } func main() { test() } ``` 输出： ```text PS C:\Users\Administrator\Desktop> go run .\test.go 111 2019-09-01 17:46:20.315 [Error] [panic.go:43] --------------------------------------- runtime error: err 1 traceback: stack: 1 true [file: C:/Users/Administrator/Desktop/test.go] [func: main.test] [line: 12] stack: 2 true [file: C:/Users/Administrator/Desktop/test.go] [func: main.main] [line: 17] stack: 3 true [file: d:/dev/go/src/runtime/proc.go] [func: runtime.main] [line: 200] stack: 4 true [file: d:/dev/go/src/runtime/asm_amd64.s] [func: runtime.goexit] [line: 1337] --------------------------------------- ```