Un mensaje de error puede incluir datos concretos además de un nombre. Esos datos permiten interpretar mejor una operación fallida, siempre que la aplicación los decodifique con la definición adecuada.
La documentación de errores personalizados de Solidity muestra que pueden llevar parámetros. Un nombre y dos valores pueden comunicar, por ejemplo, qué cantidad se solicitó y cuál estaba disponible, sin que el nombre por sí solo describa toda la situación.
En un ejemplo inventado, un error llamado CantidadInsuficiente contiene disponible=4 y solicitada=7. La interfaz debería conservar la función de cada número. Mostrar simplemente “4, 7” obliga al lector a adivinar el orden y puede invertir la explicación.
Comprueba la definición antes de traducir
Lee los nombres y tipos de los parámetros en la ABI correspondiente. Después compara la presentación de la aplicación con los valores decodificados. No deduzcas una unidad monetaria si el contrato usa unidades internas de otro tipo.
Además, la presencia de un nombre de error no autentica por sí sola su origen. Al estudiar una cadena de llamadas, mantén abierta la pregunta de dónde se generaron los datos de error y cómo llegaron a la interfaz.
Para un informe de incidencia, utiliza valores sintéticos cuando sea posible y conserva la operación consultada, la definición empleada y el texto mostrado. Así la conversación pasa de “la aplicación falla” a una discrepancia concreta que otra persona puede comprobar.
La imagen ilustra el tema; no documenta este ejemplo.