Closed wanderingbort closed 6 years ago
➤ Corey Lederer commented:
Corey Asked Bart: Is this something that we still want to do? If so, this feels like post dawn-3.0 activity?
Bart's Response: The short answer is "yes" but it is certainly post dawn-3.0
It may be post production launch.
➤ Bart Wyatt commented:
it is now post production launch 😮
related to #431 and #422 and #419
Motivation
As our tooling improves, many of the system level messages will move away from assert logs (unless
-v,--verbose
) is specified and into localized human-friendly messages. However, contracts can and will fail in spectacular ways, and the semantics/pragmatics of these failures will be impossible to deduce from the outside. For instance, overspending your allotted balance in the current currency contract outputs:This messaging is contract defined: https://github.com/EOSIO/eos/blob/da5ce85ae2a146239cc87772c47d128390993d51/contracts/eoslib/token.hpp#L93
While in this instance, the code in question is part of
eoslib
, in many other cases it will not be something EOS developers directly control. In some cases, it may not even be a well-defined assert.Ideally, that messaging would have optional localization as well.
Proposal
As an optional part of the
.abi
or as an appendix to the.abi
we allow for developer specified help text rules and localization. Currently the format of help text rules is rather fragile so, some thought will need to go into generalizing that system OR formalizing a means of error reporting fromeosd
-> http -> tools such that tools likeeosc
can properly determine, localize, and interpolate error messages.the system should allow for:
Remaining Questions