4

I have this code that will not compile :

#[pallet::error]
pub enum Error<T> {
 SomeErr{ account : T::AccountId }
}

This will not compile with the error :

AccountId associated type not found.

Alright, can I help the situation by restricting T to T: Config ? No, that will not compile either. So does that imply we can't use T and it's ATs on Errors?

Or is it a general limitation on the Error type to not be able to nest other types? Which also brings me to the question, when using map_err a common pattern to wrap perhaps a failure from some other module and emit it as our custom pallet error, do we lose the ability to nest error types?

Effectively making the e in map_err(|e| ... ) useless?

1 Answer 1

1

I think the current limitation lies in the size.

If I remember correctly, the previous discussion suggested making the encoded error 2 bytes in size and adding support for nested types.

You can nest specific errors, but not the generic one.

If you introduce generics here, what will be the impact on size...?

For more details, please refer to https://github.com/paritytech/substrate/issues/8081.

2

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.