5 ms·
Or you could have just caught panics at the top, and transformed them to errors. https://github.com/dre1080/recovr https://github.com/dre1080/recovr That's wh
by joshuak 6y ago
Or you could have just caught panics at the top, and transformed them to errors.
https://github.com/dre1080/recovr https://github.com/dre1080/recovr
That's what we do. Well we always use errors, but we can't be sure the packages we use won't panic.
- whateveracct 6y agoGo programmers also tend to have terminal systems brain, so the runtime cost of panic tends to bother them to their core :)
- erik_seaberg 6y agoIf they used unwind tables for panic, it would be cheaper than a deeply nested stack of mispredicted “if err != nil” branches. But according to https://dr-knz.net/go-calling-convention-x86-64.html https://dr-knz.net/go-calling-convention-x86-64.html they don’t, probably because you can randomly defer stuff anywhere and it isn’t statically scoped.
- zachmu 6y agoNo, that's not possible. A panic must be recovered in the goroutine in which it occurs. An unrecovered panic in any goroutine kills the entire process, not just the offending goroutine. There is no way to top-down wrap an entire go process in a recover block to keep a panic from killing your process. You have to do it in each and every goroutine.
- joshuak 6y agoTrue, which is one of the reasons why the practice of launching goroutines inside of packages is discouraged. Granted its sometimes unavoidable and some package maintainers just didn't get the memo, nevertheless when deciding on a package to use it's much easer to find dubious goroutines, than assessing if every potential panic has been handled correctly. Usually easer to fix too if warranted.