Lint issues when enabling nilerr linter.

[tslamic]

Hi! 👋

Apologies for not following the standard issue format; since this is more of a question/clarification than an issue, I think a simple description suffices. I was playing around with the linter config and enabled nilerr, which reported the following:

jsonrpc/eth_endpoint.go:319:3: error is not nil (line 312) but it returns nil (nilerr)
                return nil, nil
                ^
jsonrpc/eth_endpoint.go:419:3: error is not nil (line 416) but it returns nil (nilerr)
                return argBytesPtr(types.ZeroHash[:]), nil
                ^
jsonrpc/eth_endpoint.go:425:3: error is not nil (line 422) but it returns nil (nilerr)
                return argBytesPtr(types.ZeroHash[:]), nil
                ^
jsonrpc/eth_endpoint.go:790:3: error is not nil (line 787) but it returns nil (nilerr)
                return argBytesPtr(emptySlice), nil
                ^
jsonrpc/types.go:265:3: error is not nil (line 263) but it returns nil (nilerr)
                return nil
                ^
state/runtime/precompiled/base.go:42:3: error is not nil (line 40) but it returns nil (nilerr)
                return nil, nil

Looking at jsonrpc/eth_endpoint.go, I suspect returning nil for some errors is by design. However, in types.go and (potentially) base.go, returning nil might be a typo rather than a conscious decision.

Since I'm unfamiliar with the codebase, my assumptions might be incorrect, but I just thought I'd point it out. Happy to patch it up if you need a hand. 🙂

[laviniat1996]

Hi @tslamic,
I have converted the issue you opened to a discussion.
We are aware of this problem, it was disabled because of the legacy code we have, which we are working to refactor. Once we have the legacy code refactored, we will enable this.