-
Notifications
You must be signed in to change notification settings - Fork 182
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
Implement revert reasons #75
Comments
Now that #342 landed, we do have support to revert with properly However, we only support it in We do not yet support it with Fun fact, in Solidity
When you use it as a keyword you can provide a custom error as in A while back I created an issue that argued to turn Does anyone have opinions about that? |
I've found some really interesting discussions from Solidity regarding that:
Main take away is that Solidity seems to be focused on deprecating the In practice, one could define an error like this:
Based on that type, an ABI selector of One could then use it as
I think it would be reasonable to follow down the same path. However, it could also be interesting to explore an interface / trait based solution. That said, interfaces/traits seem to be still further away and adding an One thing to discuss would be if we still want to support To sum up, what I think we should do short term is:
@g-r-a-n-t What do you think? |
Just leaving this here as another reference: https://blog.soliditylang.org/2021/04/21/custom-errors/ |
@g-r-a-n-t @sbillig any thoughts on implementing the proposed custom error mechanics. I think it's very mvp worthy and sentiment that I get from twitter is that people seem to be quite happy with it. |
Hi! I'm not a language-expert, but I'm excited about Fe, and I hope my input can be useful:
+1 , I'd also vote to just drop the old syntax. Some interesting analysis / discussions on this topic from other Swift and other languages: https://github.com/apple/swift/blob/main/docs/ErrorHandlingRationale.rst#id49
My personal opinion, would be to treat it as a keyword. I kinda read "revert" as the equivalent to "throw" in swift for instance (https://docs.swift.org/swift-book/LanguageGuide/ErrorHandling.html) ; Having it as a statement might make it more familiar to other people too. |
What is wrong?
#74 adds support for
revert
but it does not yet add support revert reasons. We should support revert reasons.How can it be fixed
I haven't given that much thought. I guess it boils down to reserving some space for revert reasons and then calling
rever(start, end)
with the correct memory offsets but I would have to take a closer look.The text was updated successfully, but these errors were encountered: