Publicación
Comparte tu conocimiento.
Manejo de errores estándar en el marco Sui: ¿mejores prácticas y recomendaciones?
external-crates/move/move-stdlib/sources/error.move
Al explorar la implementación de los errores estándar, me di cuenta de que el repositorio de Sui utiliza localmente el error move std original, almacenado como parte de un crate () externo. Sin embargo, tuve un problema al usar esta caja externa junto con el módulo Sui almacenado en (crates/sui-framework/packages/sui-framework/Move.toml
) debido a un conflicto de dependencias. aptos-move/framework/aptos-framework/Move.toml
Al comparar esto con Aptos, observé que Aptos proporciona una API para el módulo de errores, que requiere que los usuarios usen AptosFramework (). aptos-move/framework/move-stdlib/sources/error.move
Sin embargo, el error del módulo Move en sí mismo está presente en move-stdlib (). crates/sui-framework/packages/move-stdlib/sources/error.move is missing
Esto contrasta con Sui, donde el módulo de error parece estar ausente en el directorio move-stdlib (). Mi pregunta es, ¿existe un método recomendado o equivalente para marcar errores específicos como errores estándar reales que puedan utilizarse en un entorno de varios módulos dentro del marco de Sui?
- Move CLI
Respuestas
2En el contexto del marco Sui, es una convención mantener las constantes y los errores locales en los módulos de Move en lugar de importarlos desde otros paquetes de Move. A diferencia de otros marcos como Aptos, Sui no crea un módulo Move de errores independiente. Al trabajar con Sui, se recomienda definir las constantes de error y las funciones de manejo dentro del módulo específico en el que se utilizan, evitando las importaciones desde paquetes externos. Esta convención ayuda a mantener una estructura clara y encapsulada dentro de los módulos, lo que garantiza un enfoque coherente para la gestión de errores. Si va a crear paquetes que dependan unos de otros, considere la posibilidad de organizar las constantes de error y gestionar las funciones dentro de los módulos cuando sean pertinentes, siguiendo la convención de Sui sobre la localización de constantes y errores. Este enfoque se alinea con los principios de diseño del marco y garantiza una base de código coherente dentro del ecosistema de Sui.
En el marco de Sui, el mecanismo de manejo de errores parece ser diferente al de Aptos. Aptos proporciona una API para el módulo Error Move y requiere que los usuarios usen el AptosFramework, que incluye el módulo de errores. Sin embargo, en Sui, el módulo de error parece no estar en el directorio move-stdlib.
Teniendo en cuenta esto, si desea marcar errores específicos como errores estándar en un entorno de varios módulos dentro del marco de Sui, es posible que deba crear su propio módulo de gestión de errores. Este módulo definiría los errores estándar que su aplicación necesita y proporcionaría una forma de detectar y gestionar estos errores.
Este es un ejemplo básico de cómo puedes definir un módulo Move para la gestión de errores:
module ErrorHandling {
public fun standard_error(message: vector<u8>) {
// Implement your error handling logic here
}
}
En este ejemplo, standard_error
es una función pública que toma un mensaje como parámetro. Puedes llamar a esta función siempre que quieras lanzar un error estándar.
También necesitarías crear una forma de gestionar estos errores. Esto se puede hacer en el mismo módulo o en un módulo independiente. Este es un ejemplo de cómo puedes gestionar los errores:
module ErrorHandling {
public fun standard_error(message: vector<u8>) {
// Implement your error handling logic here
}
public fun handle_error(error: vector<u8>) {
// Implement your error handling logic here
}
}
En este ejemplo, handle_error
es una función pública que toma un error como parámetro. Puede llamar a esta función siempre que desee gestionar un error.
Sabes la respuesta?
Inicie sesión y compártalo.