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:

assert_exception: Assert Exception
status_code == 200: Error
: 10 assert_exception: Assert Exception
test: assertion failed: integer underflow subtracting token balance
    {"s":"integer underflow subtracting token balance","ptr":32}
    thread-0  wasm_interface.cpp:377 assertnonei32i32

    {"name":"apply","current_validate_context->msg.type":"transfer"}
    thread-0  wasm_interface.cpp:507 vm_call

    {}
    thread-0  wasm_interface.cpp:568 apply

    {"context.msg":{"code":"currency","type":"transfer","authorization":[{"account":"initc","permission":"active"}],"data":"000000008041934b00000079b822651df401000000000000"}}
    thread-0  chain_controller.cpp:962 apply_message
...<SNIP>...

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 from eosd -> http -> tools such that tools like eosc can properly determine, localize, and interpolate error messages.

the system should allow for:

contract developers to optionally move the burden of well formed error messages outside of the contract code that lives on chain either by mapping short messages to localized/full messages or by allowing some token to represent messages from a dictionary
localization of error messages
some interpolation/templating of error messages that better handles things like lists of missing permissions

Remaining Questions

[ ] where should this live?
[ ] where should localizations live?
[ ] how crazy with the templating do we need to go?
[ ] what is a more general way of associating error output and context data with an appropriate template? (right now it is regex :barf: )

blockone-syncclient commented 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.

blockone-syncclient commented 6 years ago

➤ Bart Wyatt commented:

it is now post production launch 😮

EOSIO / eos

DAWN-488 ⁃ Allow contracts to specify help text #444

Motivation

Proposal

Remaining Questions