3 ms·
This is sorely needed to simplify error handling and getting rid of nil pointers panics. Would love to see a linter written for Go after something like this is
by lordofgibbons 2y ago
This is sorely needed to simplify error handling and getting rid of nil pointers panics. Would love to see a linter written for Go after something like this is created to ensure absolutely no naked pointer is ever returned.
- Ferret7446 2y agoI have never encountered a nil pointer panic in Go in ~5 years, after the first few months learning to actually use the language. It's basically a non-issue IMO. Just stop explicitly ignoring the errors returned from constructors.
- lordofgibbons 2y agoI've been using the Go full time since about 2013 and it's a massive issue, and has woken me and my teammates up at night. Specially, when junior engineers are involved. Why hope to catch these issues with code review if the type system/compiler can do it for you instead? Some of the most common areas that infest the code with nullable pointer types are when you have to deal with de-serializing data a lot. This is due to lack of a common built-in Optional type (I know you can define one easily, but you can't force libraries that you rely on to use that type). The best we have now is https://github.com/uber-go/nilaway https://github.com/uber-go/nilaway and it's improving with time. It does static analysis, but it has a very difficult job to do, so right now it's super slow to run, and is prone to having false-positives.