[wannabe44]

In practice you use Go with a linter, so this is not a problem in practice. I have never seen a missed error.

The problem is painstakingly and manually having to build the stack trace, and then unwrapping it few layers above if you ever need to check what error it was.

[bayindirh]

You don't need a linter. Practically Go code will not compile without declaring and using the "err" returning from a function call.

I have written a fresh example at https://files.bayindirh.io/misc/error_example.go. Give it a Go. ;)

OTOH, gopls is a great LSP, though, and it warns you about this immediately.

[comex]

The problem is that this stops working once you have multiple assignments to err in the same function.

[bayindirh]

Good point, but I personally never do that? Instead of doing (expensive) calls, I just assign the result to a variable and use that instead. Accessing to memory is pretty cheap in Go, and it's cleaned once it goes out of the scope, so why not?

Considering some expensive Go calls do the same caching underneath, this is the preferred design pattern, I assume.

[wannabe44]

What if the method only returns an error, like file.Close()?