You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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:
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
The text was updated successfully, but these errors were encountered: