Support returning error types from a realm

[moul]

Today, it returns a string representation of the pointer.

It should instead return a structure that can be processed dynamically, containing as much helpful information as possible.

The ultimate goal is to start having official typed errors that can be used by wallets and frontends to react differently, i.e., supporting "redirect errors".

[moul]

Related with #439

[jefft0]

Hi @moul. I wonder if this is related to a question we have. In GnoMobile, if BroadcastTxCommit, returns an error in bres.CheckTx.Error, then it wraps a meaningful error type such as std.OutOfGasError. (Because the error is generated by the local checks before broadcasting?) We can check the error type. But if it returns an error in bres.DeliverTx.Error then it just wraps the generic abci.StringError. (Because only an error string is returned from the validator?)

For example when we try to register a user without enough "send", it returns the string "payment must not be less than 200000000". In GnoMobile, we would like to return an error code, but it is not ideal to have to match an error message string. (This example is realm-specific, but even language-level errors like nil pointer are just returned as strings.) I ask this question in this issue because maybe the validator can return a meaningful error type. Are there plans for that?

[moul]

I propose an hybrid approach:

• Utilize emit & event built-in functions #575's logging feature, which employs an unpersisted pubsub system for cost-effective contract logging. We can extend this feature to log supplementary information from the gnovm that is not directly written in the contract, such as advanced panic handling, debugging metrics, etc. Consequently, clients can subscribe to "logging events" for the current transaction ID and receive additional metadata.
• Enhance error formatting to make it more informative and optionally typed, while maintaining conciseness for potential storage.