-
Notifications
You must be signed in to change notification settings - Fork 682
EIP-758 (Return data / revert reason strings) #116
Comments
@rmeissner Ah excellent, thank you. Sorry I missed that. |
Whoops, there was more to this issue than just fixing #114. I'll leave it open until we can discuss/decide/prioritize the other recommended changes. |
Thanks for the links @cgewecke! Looks like the remix link is broken, it ought to be https://github.com/ethereum/remix/blob/73849adc6bf0eb5f1b8198842cfb9a8f417264b9/remix-lib/src/execution/txExecution.js#L88 |
@JamesLefrere Oh great thank you (have updated original). |
The piece of this which returns the reason string in the RPC error object is complete and has been released for some time now. I recently also added the reason string to the logging output on As a result I'm closing this one as completed. Thanks, Chris! |
How about a special revert reason when a function selector doesn't exist? |
EIP-758
This topic came up in conversation with Tim yesterday around improving migrations in Truffle V5 - just leaving some resource notes here to start a discussion. Being able to get error messages from require statements would be extremely helpful.
@dekz has opened a PR here recently that parses and attaches the reason string to returned errors. This is a nice solution for ganache's current error handling but doesn't map to the
--noErrorsOnVMResponse
behavior that's probably preferable to have as a default so that ganache's behavior emulates the main clients.Remix is currently displaying the reason in a similar way - using
ethers
to do the decoding. Code for that is hereGeth has an open PR to add an rpc call / subscription type called
eth_newReturnDataFilter
which allows the caller to fetch return data in a second step (or receive it through a channel). .Additional (and ongoing) discussion about implementation details at geth 963.
From a truffle migrations standpoint
eth_newReturnDataFilter
is ideal because web3 currently injects it's own quite opaque error ("check your gas amount") into the response when a contract creation fails after hitting revert in a constructor. A common source of bewilderment (and fury) over there is receiving this message when constructing a contract with a long Zeppelin inheritance chain. A require fails deep in the constructor nest and it's quite difficult to understand what went wrong.The text was updated successfully, but these errors were encountered: