Closed joemonem closed 2 months ago
The ContractError
enum in packages/std/src/error.rs
has been enhanced with a new CustomError
variant, allowing developers to specify custom error messages. Additionally, the ADOContract
in execute.rs
has been updated to adopt a more flexible error handling approach, permitting various error types through generic parameters, thereby improving the usability and robustness of error management.
Files | Change Summary |
---|---|
packages/std/src/error.rs |
Added CustomError variant to ContractError enum |
packages/std/src/ado_contract/execute.rs |
Updated ExecuteContextFunction and execute_amp_receive to support generic error types, enhancing flexibility in error handling. |
In the meadow of code where errors reside,
A new variant blooms, with developers' pride.
Custom messages now dance in the air,
Flexibility grows, and troubles beware.
With every change, our contracts grow bright,
Tailored errors make coding a delight!
🐇✨🌼
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?
I think this can be achieved in a cleaner fashion using a generic with From<ContractError>
I am not sure if current approach is actually going to solve the problem.
External ADOs should not be forced to throw core repo's ContractError
. execute_amp_receive
function is supposed to be used for external ADOs as it is responsible for sending ibc packets but it is throwing the core repo's ContractError
and thus incompatible with external ADOs.
For the ExecuteContextFunction
type used in execute_amp_receive
,
type ExecuteContextFunction<M, E = ContractError> = fn(ExecuteContext, M) -> Result<Response, E>;
I see that it was originally designed with generic E
but forced to use ContractError
. Is there any technical problems with this?
To solve the issue, I think it should be changed like this
- type ExecuteContextFunction<M, E = ContractError> = fn(ExecuteContext, M) -> Result<Response, E>;
+ type ExecuteContextFunction<M, E> = fn(ExecuteContext, M) -> Result<Response, E>;
and update the execute_amp_receive
with generic E
parameter.
I am not sure if current approach is actually going to solve the problem. External ADOs should not be forced to throw core repo's
ContractError
.execute_amp_receive
function is supposed to be used for external ADOs as it is responsible for sending ibc packets but it is throwing the core repo'sContractError
and thus incompatible with external ADOs.For the
ExecuteContextFunction
type used inexecute_amp_receive
,type ExecuteContextFunction<M, E = ContractError> = fn(ExecuteContext, M) -> Result<Response, E>;
I see that it was originally designed with generic
E
but forced to useContractError
. Is there any technical problems with this?To solve the issue, I think it should be changed like this
- type ExecuteContextFunction<M, E = ContractError> = fn(ExecuteContext, M) -> Result<Response, E>; + type ExecuteContextFunction<M, E> = fn(ExecuteContext, M) -> Result<Response, E>;
and update the
execute_amp_receive
with genericE
parameter.
I think the only shortcoming here is that the error type needs to implement From<ContractError>
as we call verify_origin
which can return a ContractError
result.
This also requires the developer to wrap our error type as an enum type in their error type:
pub enum MyContractError {
/// Their error types
AndromedaError(AndromedaContractError)
}
Motivation
Addresses Issue #500
Implementation
Add a
CustomError
variant to ourContractError
Enum. This new variant takes a custom message as input, so external developers can display any error message they want in case they didn't find their desired Error variant in ourContractError
Testing
N/A
Version Changes
No version changes
Notes
This solution is based off the assumption that external developers will import our
ContractError
enum.Future work
We can easily add the most used custom errors as new variants to
ContractError
.Summary by CodeRabbit
ADOContract
to support a broader range of error types, improving versatility in error management during execution.