Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve error handling abstractions in wasm-transform and wasm-chain-integration #203

Open
3 tasks
abizjak opened this issue Jan 8, 2022 · 0 comments
Open
3 tasks
Labels
good first issue Good for newcomers [Prio] Low Should be fixed if time permits but can be postponed. [Type] Task An additional feature or improvement.

Comments

@abizjak
Copy link
Contributor

abizjak commented Jan 8, 2022

Task description

The interpreter and wasm-chain integration often use anyhow::Error as an error type. This is for historical reasons since during initial development this is most flexible. We then use downcast to identify whether specific errors, such as OutOfEnergy occurred. We also have a number of other concrete errors that I needed during testing. Still there are some remaining errors that are just bail!("arbitrary string").

The ideal way of doing error handling is that each of the library methods (i.e., all of parsing, validation, interpreter) would return a precise error, which would be an enum. anyhow::Error should only be used in cargo-concordium at the application level.

This task is to get to this point.

Sub-tasks

  • replace anyhow::Error in wasm-transform functions with precise errors. Using thiserror crate to handle the boilerplate
  • replace anyhow::Error in wasm-chain-integration functions with precise errors. Using thiserror crate to handle the boilerplate
  • propagate changes

This will make error handling more robust. In particular with the current setup checking whether execution failed with out of energy, or whether it failed for some other reason is not clean and transparent.

@abizjak abizjak added good first issue Good for newcomers [Prio] Low Should be fixed if time permits but can be postponed. [Type] Task An additional feature or improvement. labels Jan 8, 2022
@abizjak abizjak transferred this issue from Concordium/concordium-wasm-smart-contracts Aug 12, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers [Prio] Low Should be fixed if time permits but can be postponed. [Type] Task An additional feature or improvement.
Projects
None yet
Development

No branches or pull requests

1 participant