Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API error definition mechanism that is type-safe across runtime boundaries #7563

Open
petar opened this issue Jul 28, 2020 · 3 comments
Open
Labels
kind/enhancement A net-new feature or improvement to an existing feature

Comments

@petar
Copy link
Contributor

petar commented Jul 28, 2020

At the moment, go-ipfs core implementation returns plain Go errors (often ad-hoc ones, creatde with fmt.Errorf), which forces all client (e.g. HTTP API clients) code to discriminate errors based on ad-hoc string and sub-string matching.

We would like to design a custom error type, which can facilitate (and make safe) error discrimination in two settings:

  • when errors are returned as Go errors (i.e. when calling a Go API object directly), and
  • when errors are returned as strings (or structures) over the wire (e.g. as in the HTTP API case)

The mechanism should support annotations and ideally stacking (wrapping) with source line info.

An example of where this problem occurs, when writing HTTP clients one is forced to do this:
https://github.com/ipfs/go-ipfs-http-client/pull/114/files#diff-95ad8db4f69eb5c860efd5d90d02d3d3R94

@petar petar added the kind/enhancement A net-new feature or improvement to an existing feature label Jul 28, 2020
@welcome
Copy link

welcome bot commented Jul 28, 2020

Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review.
In the meantime, please double-check that you have provided all the necessary information to make this process easy! Any information that can help save additional round trips is useful! We currently aim to give initial feedback within two business days. If this does not happen, feel free to leave a comment.
Please keep an eye on how this issue will be labeled, as labels give an overview of priorities, assignments and additional actions requested by the maintainers:

  • "Priority" labels will show how urgent this is for the team.
  • "Status" labels will show if this is ready to be worked on, blocked, or in progress.
  • "Need" labels will indicate if additional input or analysis is required.

Finally, remember to use https://discuss.ipfs.io if you just need general support.

@Stebalien
Copy link
Member

Yeah... I'm just not sure how to properly serialize such errors over an RPC layer unless we create a globally agreed on table of error codes (which might just be the way to go?). That's what we do in https://github.com/filecoin-project/specs-actors/blob/master/actors/runtime/exitcode/exitcode.go.

@petar
Copy link
Contributor Author

petar commented Aug 21, 2020

This seems like a potential drop-in solution: https://github.com/cockroachdb/errors

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement A net-new feature or improvement to an existing feature
Projects
None yet
Development

No branches or pull requests

2 participants