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 return type in metadata to allow common errors #1207

Closed
Tracked by #1265
athei opened this issue Apr 1, 2022 · 0 comments · Fixed by #1450
Closed
Tracked by #1265

Change return type in metadata to allow common errors #1207

athei opened this issue Apr 1, 2022 · 0 comments · Fixed by #1450
Labels
A-ink_metadata [ink_metadata] Work item B-enhancement New feature or request

Comments

@athei
Copy link
Contributor

athei commented Apr 1, 2022

Currently, the metadata defines the return type of a message (or constructor) as exactly the type that is returned by the message itself.

This doesn't allow us to return any error that isn't defined by the contract itself. For example, the dispatch of a contract call to the individual messages is not handled by user code but by code generated by ink! macros. The way how the metadata is defined won't allow ink! to return an error in case a message isn't found (as the return type is defined by user code). The only thing ink! can emit in this case is a trap which prevents the caller from learning about a missing message.

What we should to is define the return type of messages (and constructors) in terms of an enum that allows us to define common errors which are defined within the ABI rather than within user contract code. As long as we only extend the enum and make it clear that one should not match it exhaustively it will be forward compatible:

enum Error<T> {
    Custom(T),
    UnknownMessage,
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-ink_metadata [ink_metadata] Work item B-enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants