How can errors be marked as standard in Sui to be used in Move module environments?

Question

While exploring the usage of standard errors in Sui Move, I noticed that the Sui repository utilizes an original Move std error locally stored as part of an external crate. The external crate, specifically external-crates/move/move-stdlib/sources/error.move, causes a dependency conflict when used alongside the Sui Move module stored in crates/sui-framework/packages/sui-framework/Move.toml.

In comparison, Aptos provides an API for the error module, where users are required to use the AptosFramework stored in aptos-move/framework/aptos-framework/Move.toml. The error module, however, resides in the move-stdlib directory at aptos-move/framework/move-stdlib/sources/error.move.

In the case of Sui, both sui-framework (crates/sui-framework) and move-std (crates/sui-framework/packages/move-stdlib) are present, but the error Move module is absent from the move-stdlib directory at crates/sui-framework/packages/move-stdlib/sources/error.move (this file is missing). My question is: Is there a recommended or equivalent way in Sui Move to designate an error as an actual standard error that can be used in a multiple Move module environment?

Jeremy · Answer

You can create two Move packages, one which depends on another. In the Move package which imports, import convenience function to sugar coat error. However if you look at code in Sui, the convention is to keep constants and errors local to Move module (s) rather than importing from other packages - this is also why the sui framework doesn't create an error module, so that would be the recommended way. Aptos and Sui differ in error and other conventions.

If you have further questions or need assistance with a different approach, feel free to ask them here;

Post

Share your knowledge.

How can errors be marked as standard in Sui to be used in Move module environments?

Answers

Do you know the answer?

Earn Your Share of 1000 Sui