You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
enumError<T>{Custom(T),UnknownMessage,}
The text was updated successfully, but these errors were encountered:
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:
The text was updated successfully, but these errors were encountered: