Do not use reserved JSON-RPC error codes

[BelfordZ]

Copy from https://github.com/ethereum/go-ethereum/issues/20050

Let's just fix the specific issue, use of -32000. Of course there are other problems with the current json rpc errors, but none as severe as this one.

System information

Geth version: all OS & Version: all

Expected behaviour

Go ethereum returns errors whose code is not in the range -32768 to -32000 inclusive.

this means that the error defined as

{
  "code": -32000,
  "message": "Invalid input",
  "data": "- Missing or invalid parameters"
}

Should have a code that is 1 greater than the current greatest error code, so -32005

Actual behaviour

As described by eip-1474, -32000 is in use

Steps to reproduce the behaviour

call any json rpc method without parameters

curl -XPOST localhost:8545 -H "Content-Type: application/json" -d '{"jsonrpc": "2.0","id": 1, "method": "eth_getBlockByNumber", "params": []}'

[tzdybal]

From JSON-RPC spec:

code	message	meaning
-32000 to -32099	Server error	Reserved for implementation-defined server-errors.

One can argue that invalid input / missing or invalid parameters an example of implementation-defined server-error. Missing params can be seen as server error (not application error), as server may not be able to execute application without params.

[tzdybal]

EIP-1474 is still a draft and it proposes standardization of error codes, with well defined codes from range -32000 to -32099.

Moreover changing code from -32000 to -32005 doesn't solve the issue, because it's still the same code range from JSON-RPC spec.

[BelfordZ]

@tzdybal If this was the case, wouldn't the error message be "Server Error" ?

[BelfordZ]

Moreover changing code from -32000 to -32005 doesn't solve the issue, because it's still the same code range from JSON-RPC spec.

right. I guess we do need to overhaul all the errors then. =(