Open dhruvja opened 7 months ago
HI @dhruvja, thanks for the input.
I'm not opposed to implementing this in principle, but there is a general challenge that it's not really possible to have an injective implementation of this trait for InvokeContractError
so there would be some loss of information.
This is usually a lot simpler to accept on a case by case basis rather than in a generic implementation.
HI @dhruvja, thanks for the input.
I'm not opposed to implementing this in principle, but there is a general challenge that it's not really possible to have an injective implementation of this trait for
InvokeContractError
so there would be some loss of information.This is usually a lot simpler to accept on a case by case basis rather than in a generic implementation.
Do you mean its difficult to include the generics when we implement the trait?
No, I meant that to implement Reject
we need to assign codes in the set i32::MIN..-1
to values of the CallContractError
and in general it is not possible to do so without losing information, meaning that there would be two values that would map to the same status code. This is unsatisfactory which is why the trait is not implemented at the moment.
Moving this over to the correct repository.
Description When a cross contract call is made, it returns
CallContractError
which doesnt seem to implementReject
trait which the entrypoint method expect to return. So aFrom
trait has to be implemented.Solution Implementing
Reject
trait onCallContractError
itself will help users just return those errors directly from entrypoint without needing to write wrappers.A From trait for Cis2ClientError which itself is a wrapper for CallContractError looks like below.
Would love to know what you guys think regarding having this trait implemented?