Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change ABI to provide a string reason for a throw in Solidity #62

Closed
VoR0220 opened this issue Jan 25, 2016 · 16 comments
Closed

Change ABI to provide a string reason for a throw in Solidity #62

VoR0220 opened this issue Jan 25, 2016 · 16 comments
Labels

Comments

@VoR0220
Copy link
Member

VoR0220 commented Jan 25, 2016

Currently a throw does not supply any particular reason why the contract threw, and this could get confusing not just for developers but for people who are utilizing contracts as they grow and become more complex. More information is a nice thing especially when dealing with something as new as Solidity. Would love to hear opinion on this.

@axic
Copy link
Member

axic commented Jan 25, 2016

👍

@nmushegian
Copy link

This is not an ABI issue but an EVM issue. This requires adding a new opcode. It should allow you to revert all state changes in your scope while returning a value you specify. It may require adding special VM state to signify whether the last call was an exception or not.

@VoR0220
Copy link
Member Author

VoR0220 commented Jan 28, 2016

Or why not just modify the current opcode used for throw?

@VoR0220
Copy link
Member Author

VoR0220 commented Jan 28, 2016

ahhh...that's because it's BadDestJump...either way, is there any agreement that this should happen?

@axic
Copy link
Member

axic commented Feb 15, 2016

I think it would be beneficial for error reporting. How do you propose to deliver that message though?

@VoR0220
Copy link
Member Author

VoR0220 commented Feb 15, 2016

perhaps take a chunk of gas out of the thrown gas to pass an in memory string message back to the console? These are just initial thoughts. It would seem from the above comments that either a change to the opcode, or a new opcode, will be necessary.

@alexvandesande
Copy link

Could this be solved without a new opcode by having the EVM save any returns sent before the throw?
So you'd do something like this:

return(23, 'deadline not passed');
throw;

But I agree that having a throw(error) would be more beneficial

@VoR0220
Copy link
Member Author

VoR0220 commented Feb 17, 2016

But then the throw won't be hit.

@axic
Copy link
Member

axic commented Feb 17, 2016

Just throwing in: there could be a dedicated event topic set for this?

@VoR0220
Copy link
Member Author

VoR0220 commented Feb 17, 2016

Maybe... @alexvandesande you seem to have better knowledge of the EVM than I, what would you propose?

@chriseth
Copy link
Contributor

This is very hard to impossible to implement in the current exception setup (if you revert the state you cannot store any information) and I doubt we will extend the exception mechanism in the EVM as this is only a hack anyway.

@VoR0220
Copy link
Member Author

VoR0220 commented Feb 17, 2016

@chriseth couldn't you just send the string back in memory?

@wanderer wanderer added the ABI label Apr 14, 2016
@SCBuergel
Copy link
Contributor

Getting a "bad jump dest" instead of "array index out of bounds" makes it close to impossible for new developers to figure out what is going on. We really need some solution to make runtime bugs more debuggable - or to build platforms which allow debuggable code to be written.

@janx
Copy link
Member

janx commented Apr 28, 2016

+1. We really need some solution to make runtime bugs more debuggable.

Can we use data to pass reason string back (instead of set to []) on OOG? https://github.com/ethereum/pyethereum/blob/develop/ethereum/vm.py#L140

@github-actions
Copy link

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

@github-actions github-actions bot added the stale label Jan 17, 2022
@github-actions
Copy link

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.

bumblefudge added a commit to bumblefudge/EIPs that referenced this issue Feb 16, 2024
Polkadot namespace CAIP-2 and CAIP-10 definitions
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

10 participants