4

Is there any way to tell the construct_runtime! macro to build/export a top-level Error enum type in the same way it provides the top-level Call and Event types?

As far as I can tell the only way to decode an Error retrieved from the runtime is to use the Metadata (which is a little cumbersome), since the inner ModuleError erases the error message - presumably to save storage.

It would be nice if it was possible to do something like this:

match dispatch_error {
    DispatchError::ModuleError(module_error) => RuntimeError::from(module_error),
    _ => // do something else
}

A concrete use case for this would be a client that wants to submit and watch an extrinsic, and be able to show the user a useful error message.

Pseudo-code:

// Imagine we have a top-level runtime::Error type.
fn submit_and_watch(ex: Extrinsic) -> Result<Vec<runtime::Event>, runtime::Error> {
    let ex_hash = author.submitExtrinsic(ex);
    let ex_events = get_extrinsic_events(ex_hash);

    if let Some(ex_failed) = ex_events.find(|e| matches!(e, System::ExtrinsicFailed { .. })) {
        // Can't convert to string because `dispatch_error` erases
        // the error message.
        // Retrieving the error message currently requires (i think?)
        // parsing the metadata.
        // If we had a top-level Error type with associated conversion
        // traits, we could do it like this:
        Err(runtime::Error::from(ex_failed.dispatch_error))
    } else {
        Ok(ex_events)
    }
}

2 Answers 2

1

Is there any way to tell the construct_runtime! macro to build/export a top-level Error enum type in the same way it provides the top-level Call and Event types?

No that is not possible.

You also don't have included any reasoning on why you need this, otherwise I could maybe have given an answer with more content.

1
  • 1
    I've edited the question to add a specific use case. But I would also argue it's just generally a little unintuitive that FRAME aggregates the pallet::Call and the pallet::Event, but not the pallet::Error. (Given that the calls, events, and errors are all very much linked, ie. a call can emit events and return errors). Nov 14, 2022 at 10:20
0

So, why not use DispatchError?

I think this could provide enough information for users.

5
  • Sorry - should have been clearer - DispatchError erases the error message when it's encoded. Nov 14, 2022 at 10:25
  • (Have edited the question to make this clearer) Nov 14, 2022 at 10:27
  • Interesting. For me, module index + error index is enough. PolkadotApps also return the error name only (which was indexed by the module index + error index). But yes, I think I don't have any better solutions. Nov 14, 2022 at 10:29
  • 1
    It's enough, but my point is it could be much easier. The PolkaJs does it (I think) is by parsing the metadata. Contrast this with the Event type, which doesn't require this. Nov 14, 2022 at 12:15

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.