Polywrap Specific Error Structure

[dOrgJelli]

Currently, we utilize basic strings for errors, wrapping them within the various languages we have software in (JavaScript & AssemblyScript Error structure, Rust's Err structure, etc).

In the same way that we have standardized structures for the various cross-module operations we support (invoke & subinvoke for example), we should have a standardize error structure that is used.

Information within this structure would include:

1. Error Message
2. Source-map Info (file, line, column)
3. URI
4. Sub-Errors

Utilizing this information, we can re-create an error-stack, enabling them to further debug where the root cause came from.

Currently we do this through string concatenation & "good faith" that the error propagators in the stack appropriately concatenate to the error string.

Utilizing this method it'd be standard to "push" your error to the stack, and return it to the caller/user of your wrappers/plugins.

Example error stack:

message: "DeFiWrapper: Failed to fetch token data"
source: {file: "./query/index.ts", row: 102, col: 20}
uri: "w3://ens/defiwrapper.eth"
  > message: "UniswapTokenResolver: Unknown pair address"
    source: {file: "./query/pairs/resolver.ts", row: 40, col: 84}
    uri: "w3://ens/uni.resolvers.defiwrapper.eth"
    > message: "Ethereum: Invalid address '0xBAD_ADDRESS'"
      source: {file: "./src/resolver.ts", row: 4343, col: 63}
      uri: "w3://ens/ethereum.wrappers.eth"
..........

[dOrgJelli]

Here's a quick brainstorm from @Niraj-Kamdar
https://hackmd.io/uuqcNzpCTwKDrbwSNp1sJg

[krisbitney]

To me, I think we just want to make sure we have proper error messaging in various common scenarios. If I had to try and list them now it'd be:

• App Dev: invoking a wrapper that's not found
• App Dev: invoking a wrapper with wrong arguments
• App Dev: invoking a wrapper method that doesn't exist
• Client Internal: subinvoking a wrapper that's not found
• Client Internal: error inside of a subinvoked wrapper multiple layers deep
• Client Internal: tried invoking a wrapper that's not a compatible version
• Wrapper Dev: handling errors from subinvoked wrappers (not found, internal error, etc etc)

You start to get the idea. The idea is that we should have a more robust system around error messaging within the context of wrapper execution. This will allow users to better understand what's happened, and developers to better program around potential error scenarios (dep not found, dep intern error, etc etc).

[krisbitney]

My current thoughts are:

1. create InvokeError class
2. make InvokeError class serializable in msgpack
3. create bindings for as/rs versions of InvokeError
4. instead of Result<T, string>, subinvocations will return Result<T, InvokeError>
5. instead of Result<T, Error>, client invocations will return Result<T, InvokeError>
6. InvokeError can be extended by UriResolutionError and possibly others?
7. InvokeError can have a pointer to another InvokeError, allowing for a linked list of errors that occurred during execution (e.g. using the "cause" property commonly supported in JS errors)