> Putting error nil checks into a function is an anti-pattern in Go. I assume you mean into a helper function like I've done with check()? If so, I agree with

> Putting error nil checks into a function is an anti-pattern in Go. I assume you mean into a helper function like I've done with check()? If so, I agree with you for normal "production" Go code. But for simple throw-away scripts you don't want half your code littered with error handling, when you could just throw a stack trace. > There is no need to worry about the LOC count of your error checking code. Well, it means some functions are more than half error handling, obscuring the guts of what a function actually does. Even the Go language designers agree that Go's error handling is too verbose, hence proposals like this from Russ Cox: https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md https://go.googlesource.com/proposal/+/master/design/go2draf... (there are many other proposals, some from the Go team) > inb4 this ends up on pcj im not shur wut pcj meenz