Polywrap Specific Error Structure

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:

Error Message
Source-map Info (file, line, column)
URI
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"
..........

@Niraj-Kamdar

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

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).

My current thoughts are:

create InvokeError class
make InvokeError class serializable in msgpack
create bindings for as/rs versions of InvokeError
instead of Result<T, string>, subinvocations will return Result<T, InvokeError>
instead of Result<T, Error>, client invocations will return Result<T, InvokeError>
InvokeError can be extended by UriResolutionError and possibly others?
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)

Navigation Menu

Repository navigation

Polywrap Specific Error Structure #701

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Polywrap Specific Error Structure #701

Description

Activity

dOrgJelli commented on Mar 4, 2022

krisbitney commented on Nov 12, 2022

krisbitney commented on Nov 15, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions