Re:Conc: Better Structured Concurrency for Go
by loeg on Wednesday January 11, 2023 @09:06PM
(#34348144)
Go panics should not be used for very common errors.
[ Parent
| on HN ]
Re:Conc: Better Structured Concurrency for Go
by erik_seaberg on Wednesday January 11, 2023 @09:36PM
(#34348438)
A lot of very common operations can panic: division, dereferencing pointer or interface, indexing/slicing an array/slice/string, asserting the type of an interface, and converting a slice to pointer to array. It’s possible to check, but I’ve never seen a tool that verifies you never use any of these without checking.
And there are some operations where you cannot check in advance whether a panic will happen: comparing interfaces (underlying values might not be fully comparable), indexing a map (could blow up during any concurrent write), and closing or sending to a closed channel.
Re:Conc: Better Structured Concurrency for Go
by jaitsu on Thursday January 12, 2023 @09:10AM
(#34353693)
You can recover from a panic though, so if you are implementing something that may panic you should have some sensible defer/recover in there if you can't afford to have your process crash.
Re:Conc: Better Structured Concurrency for Go
by preseinger on Thursday January 12, 2023 @06:32PM
(#34361798)
Division by zero, dereferencing a nil pointer, invoking methods on a nil interface, invalid indexing of an array, unchecked type assertions -- these are not common operations! These are always easily detectable programmer errors.