construct_runtime macro needs to generate runtime Error type

[xlc]

It needs to generate runtime Error type similar to how it generate runtime Event type so different module error can all Into<T::Error> where type Error: From<Error> + From<system::Error> + any_other_used_module::Error

Otherwise decl_error is much less useful

Follow up of #2880 #3433

[bkchr]

Why? Where do we need generic errors? Please provide an example.

[xlc]

This code https://github.com/laminar-protocol/open-runtime-module-library/blob/master/tokens/src/lib.rs

if I add type Error = Error in decl_module, the dispatchable call return type will be DispatchResult<Error>. but ensure_signed returns system::Error, which will stops me doing let from = ensure_signed(origin)?; because system::Error can't convert to Error.

So I would like to add type Error: From<Error> + From<system::Error> + From<LookupError> to my module Trait and make the module error type type Error = T::Error. Now it will be able to return any of the supported error in my dispatchable calls.

The remaining problem will be construct a type satisfies the type bonds for T::Error. It should be generated by construct_runtime (or impl_outer_error).

[thiolliere]

My feeling is that an error is different from an event, if you call let's say staking module and the error received is balance module saying balance too low, you may not be able to know what triggered this error, staking module must put meanings on what has triggered this too low balance.

On the other hand an event is meaningfull by itself, however it has been triggered this event happened on chain.

[thiolliere]

considering this discussion #4385 (comment)
I can finally understand that error could be treated like an event, the user would just have an "event" related to what error happened and to further dig into that they would use different tools

EDIT: but what confused me is that this is very different from what a rust error should be, that is to say a meaning full message from the called function with possibly some wrapped origin.

[xlc]

If we don't have the limitation of onchain storage, we can totally just use a popular Rust error handling library and good to go. But with the constraints, we just can't retain all the details.

What we can do is maybe come out some macro that switch between the lite error code or with full error stack trace based on std feature. But this should happen after we have the lite error code version fully implemented.

[xlc]

Fixed by #4449