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

Return IbcReceiveResponse (no Result wrapper) from ibc_packet_receive #909

Closed
ethanfrey opened this issue Apr 28, 2021 · 4 comments
Closed
Milestone

Comments

@ethanfrey
Copy link
Member

We really want to discourage returning errors - they should return success and an error acknowledgement. A few techniques are documented in IBC.md now since #885

To make this more explicit we can just prevent returning an error. This would be different than all other entry points, but maybe desirable. Open for feedback (do it or close issue).

@ethanfrey ethanfrey added this to the 1.0.0 milestone Apr 28, 2021
@webmaster128
Copy link
Member

On the other hand: if people start to use panics instead, it gets even worse then returning errors.

@webmaster128 webmaster128 self-assigned this Jun 23, 2021
@webmaster128 webmaster128 removed their assignment Jul 13, 2021
@ethanfrey
Copy link
Member Author

I think the api interface should allow returning errors (you are right, panic is worse).

I did add some extensive documentation on both receiving packets and on error handing in receive

Maybe that is enough to close this issue?

I would be happy if some other devs read those docs and make a concrete issue if anything is missing there, which I can close by improving the docs.

@ethanfrey
Copy link
Member Author

Writing an IBC contract is non-trivial and people will need to read docs to understand it. We cannot encode all this info in the type system.

I would also love to have a larger collection of IBC examples to demo...

@webmaster128
Copy link
Member

Great, let's keep as is for consistency. Best practive will emerge for how to converts errors to acknowledgements.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants