Error handling (strings, pain to refactor)

[dcatki]

No description provided.

[8e8b2c]

Some options:

Error details as delimited json string

Since WasmError encodes all guest errors as a string, we could makes error details easier to parse by encoding as a json object within the message itself. E.g. instead of the js client receiving:
{"name":"internal_error","message":"Source chain error: InvalidCommit error: Recipe needs at least 1 trusted author"}
It could instead receive:
{"name":"internal_error","message":"Source chain error: InvalidCommit error: __ERR_START__{"type":"InvalidRecipe","reasons":[{"type":"NoTrustedAuthors"},{"type":"UndeclaredVar","var_name":"foo"}]}__ERR_END__"}

And to complement this we could generate TS counterparts:

type InvalidRecipeReason = 
  | { type: "NoTrustedAuthors" }
  | { type: "UndeclaredVar", var_name: string }
  // ...
  
type HoloomError = 
  | { type: "InvalidRecipe", reasons: InvalidRecipeReason[] }
  // ...

Extracting this information can then be done by parsing the string between the delimiters.

Return ExternResult<SomeNestedTypedResult>

Coordinator functions could return errors as 'successes' to take advantage of builtin msgpack serialisation. One advantage is that is becomes simpler to bind esoteric error type to only their relevant functions.

The biggest flaw with this approach is that most hdk functions already return ExternResult, so we're already forced to be interpreting an error string much of the time.

[8e8b2c]

Spike for setting out validation rejection reason pattern:
#101