Closed haltman-at closed 1 year ago
Note: Significantly rewrote the original issue after determining it was more general than I originally thought.
The design choice behind this is that if you reach the catch block, then the call reverted. Other reasons for failure might not lead to the catch block. This is in line with try-catch not being available on internal calls.
Hi everyone! This issue has been closed due to inactivity. If you think this issue is still relevant in the latest Solidity version and you have something to contribute, feel free to reopen. However, unless the issue is a concrete proposal that can be implemented, we recommend starting a language discussion on the forum instead.
Note that while this has been closed, we're aware the underlying problem did not disappear. We just have too many duplicate issues about this. Here's a recent one with updated syntax proposals that would address this: https://github.com/ethereum/solidity/issues/13869#issuecomment-1422879881. Feedback is welcome.
Description
(Note: I rewrote this issue after realizing it's more general than I originally thought.)
The
try
/catch
construction is supposed to allow one to catch errors from external calls and handle them. But, Solidity also makes various checks of its own both before and after making an external call, and will error if these checks fail. If the external call in question has an associatedtry
/catch
, and an applicablecatch
block exists, then Solidity should jump to thecatch
block instead of erroring.For post-call checks, which
catch
block to jump to should be determined the normal way, based on the data returned. (E.g., if no data was returned, you would jump to thecatch (bytes memory x)
block if it exists, and revert if not.)For pre-call checks, you have to go based on what the returned data would be, I guess. Fortunately as best I can tell the only pre-call check Solidity makes is whether the called has any code. (I'm unclear why, it doesn't seem like this would save on gas when no ether is being transferred?) So in this case, if the check fails, you can say that the returned data would have been an empty
hex""
. So this is still handleable. I suspect if any other pre-call checks are ever added, they will likely also have this property, that if they can fail you can say the returned data would have beenhex""
.Environment
Steps to Reproduce
Pre-call example
The
run()
function should returnhex""
, but instead it reverts.Post-call example
The
run()
function should returnhex""
, but instead it reverts.