Wrap error structure

[krisbitney]

This PR adds a custom WrapError error structure that is capable of parsing errors from strings, allowing us to improve error formatting and provide additional information for debugging.

Example error output for URI Resolution Exception:

    WrapError: SubInvocation exception encountered
    code: 50 WRAPPER INVOKE ABORTED
    uri: wrap://fs//Users/kris/WebstormProjects/monorepo/packages/test-cases/cases/wrappers/wasm-as/subinvoke-error/invoke/build
    method: subWrapperNotFound
    args: {
      "a": 1,
      "b": 1
    } 
    source: { file: "~lib/@polywrap/wasm-as/containers/Result.ts", row: 171, col: 13 }
    
    Another exception was encountered during execution:
    WrapError: Unable to find URI wrap://ens/not-found.eth.
    code: 27 URI NOT FOUND
    uri: wrap://ens/not-found.eth
    uriResolutionStack: [
      "wrap://ens/not-found.eth => PackageToWrapperCacheResolver",
      [
        "wrap://ens/not-found.eth => UriResolverAggregator",
        [
          "wrap://ens/not-found.eth => StaticResolver - Miss",
          "wrap://ens/not-found.eth => ExtendableUriResolver",
          [
            "wrap://ens/ipfs-resolver.polywrap.eth => PackageToWrapperCacheResolver (Cache) => wrapper (wrap://ens/ipfs-resolver.polywrap.eth)",
            "wrap://ens/not-found.eth => ResolverExtension (wrap://ens/ipfs-resolver.polywrap.eth)",
            "wrap://ens/ens-resolver.polywrap.eth => PackageToWrapperCacheResolver (Cache) => wrapper (wrap://ens/ens-resolver.polywrap.eth)",
            "wrap://ens/not-found.eth => ResolverExtension (wrap://ens/ens-resolver.polywrap.eth)",
            "wrap://ens/fs-resolver.polywrap.eth => PackageToWrapperCacheResolver (Cache) => wrapper (wrap://ens/fs-resolver.polywrap.eth)",
            "wrap://ens/not-found.eth => ResolverExtension (wrap://ens/fs-resolver.polywrap.eth)",
            "wrap://ens/http-resolver.polywrap.eth => PackageToWrapperCacheResolver (Cache) => wrapper (wrap://ens/http-resolver.polywrap.eth)",
            "wrap://ens/not-found.eth => ResolverExtension (wrap://ens/http-resolver.polywrap.eth)",
            "wrap://ipfs/QmfRCVA1MSAjUbrXXjya4xA9QHkbWeiKRsT7Um1cvrR7FY => PackageToWrapperCacheResolver (Cache) => wrapper (wrap://ipfs/QmfRCVA1MSAjUbrXXjya4xA9QHkbWeiKRsT7Um1cvrR7FY)",
            "wrap://ens/not-found.eth => ResolverExtension (wrap://ipfs/QmfRCVA1MSAjUbrXXjya4xA9QHkbWeiKRsT7Um1cvrR7FY)"
          ]
        ]
      ]
    ]

Example error output for exception thrown during Wasm invocation:

    WrapError: SubInvocation exception encountered
    code: 50 WRAPPER INVOKE ABORTED
    uri: wrap://fs//Users/kris/WebstormProjects/monorepo/packages/test-cases/cases/wrappers/wasm-as/subinvoke-error/invoke/build
    method: throwsInTwoSubinvokeLayers
    args: {
      "a": 1,
      "b": 1
    } 
    source: { file: "~lib/@polywrap/wasm-as/containers/Result.ts", row: 171, col: 13 }
    
    Another exception was encountered during execution:
    WrapError: SubInvocation exception encountered
    code: 50 WRAPPER INVOKE ABORTED
    uri: wrap://ens/bad-math.eth
    method: subInvokeWillThrow
    args: {
      "0": 130,
      "1": 161,
      "2": 97,
      "3": 1,
      "4": 161,
      "5": 98,
      "6": 1
    } 
    source: { file: "~lib/@polywrap/wasm-as/containers/Result.ts", row: 171, col: 13 }
    
    Another exception was encountered during execution:
    WrapError: __wrap_abort: I threw an error!
    code: 50 WRAPPER INVOKE ABORTED
    uri: wrap://ens/bad-util.eth
    method: iThrow
    args: {
      "0": 129,
      "1": 161,
      "2": 97,
      "3": 0
    } 
    source: { file: "src/index.ts", row: 5, col: 5 }

Example error output for exception thrown during plugin wrapper invocation:

    WrapError: I'm throwing!
    code: 50 WRAPPER INVOKE ABORTED
    uri: wrap://plugin/mock
    method: methodThatThrows
    args: {} 
    source: { file: "/Users/kris/WebstormProjects/monorepo/packages/js/client/src/__tests__/helpers/mockPluginRegistration.ts", row: 13, col: 17 }

Closes #701

[dOrgJelli]

🔥 🔥 🔥 🔥 🔥 🔥

[nerfZael]

In cases where we're reading from a buffer, and we get a zero there, I think the buffer should be treated as corrupted and not a valid WrapError. I do not think we should be allowing undefined states for an enum we control. The error codes, IMO, should start at 1.

Still, I am fine with keeping this for the time being and being more strict about the codes in the future.

[nerfZael]

There's 2 things one can parse: serialized WrapErrors and errors from wasm modules (which may or may not be WrapErrors).

• The serialized WrapError parsing logic should be in the WrapError, or somewhere close. It is easy to parse since we know the structure and does not need regex.
• The wasm module error parsing logic should be in wasm-js. And since it can be anything regex is fine there.

The parsing logic here is both of those things.

[krisbitney]

@nerfZael

Somehow I can't reply to some of your messages so I'm responding here.

In cases where we're reading from a buffer, and we get a zero there, I think the buffer should be treated as corrupted and not a valid WrapError. I do not think we should be allowing undefined states for an enum we control. The error codes, IMO, should start at 1.

Still, I am fine with keeping this for the time being and being more strict about the codes in the future.

I removed UNKNOWN and am starting the enum at 1.

There's 2 things one can parse: serialized WrapErrors and errors from wasm modules (which may or may not be WrapErrors).

The serialized WrapError parsing logic should be in the WrapError, or somewhere close. It is easy to parse since we know the structure and does not need regex.
The wasm module error parsing logic should be in wasm-js. And since it can be anything regex is fine there.
The parsing logic here is both of those things.

All errors from Wasm modules are made to be of type WrapError.

It is possible that a message is not a stringified WrapError, but still we need to check whether it is or not (I explain why in your other question about parse). The parse method returns undefined when a message is not a WrapError, in which case message is used as the error message in a new WrapError.

[nerfZael]

@nerfZael

Somehow I can't reply to some of your messages so I'm responding here.

In cases where we're reading from a buffer, and we get a zero there, I think the buffer should be treated as corrupted and not a valid WrapError. I do not think we should be allowing undefined states for an enum we control. The error codes, IMO, should start at 1.
Still, I am fine with keeping this for the time being and being more strict about the codes in the future.

I removed UNKNOWN and am starting the enum at 1.

There's 2 things one can parse: serialized WrapErrors and errors from wasm modules (which may or may not be WrapErrors).
The serialized WrapError parsing logic should be in the WrapError, or somewhere close. It is easy to parse since we know the structure and does not need regex.
The wasm module error parsing logic should be in wasm-js. And since it can be anything regex is fine there.
The parsing logic here is both of those things.

All errors from Wasm modules are made to be of type WrapError.

It is possible that a message is not a stringified WrapError, but still we need to check whether it is or not (I explain why in your other question about parse). The parse method returns undefined when a message is not a WrapError, in which case message is used as the error message in a new WrapError.

We can address this in a followup PR when we use msgpack for error serialization

[krisbitney]

@nerfZael
Somehow I can't reply to some of your messages so I'm responding here.

In cases where we're reading from a buffer, and we get a zero there, I think the buffer should be treated as corrupted and not a valid WrapError. I do not think we should be allowing undefined states for an enum we control. The error codes, IMO, should start at 1.
Still, I am fine with keeping this for the time being and being more strict about the codes in the future.

I removed UNKNOWN and am starting the enum at 1.

There's 2 things one can parse: serialized WrapErrors and errors from wasm modules (which may or may not be WrapErrors).
The serialized WrapError parsing logic should be in the WrapError, or somewhere close. It is easy to parse since we know the structure and does not need regex.
The wasm module error parsing logic should be in wasm-js. And since it can be anything regex is fine there.
The parsing logic here is both of those things.

All errors from Wasm modules are made to be of type WrapError.
It is possible that a message is not a stringified WrapError, but still we need to check whether it is or not (I explain why in your other question about parse). The parse method returns undefined when a message is not a WrapError, in which case message is used as the error message in a new WrapError.

We can address this in a followup PR when we use msgpack for error serialization

Okay, sounds good.

[nerfZael]

LGTM!