-
Notifications
You must be signed in to change notification settings - Fork 54
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
Provide access to original error from json.Unmarshal #83
Comments
@Arqu I'd like to work on this if possible. |
@aakhan1 Absolutely appreciated, as you see time is tight, and help like this really polishes some of the rough edges. A PR is more than welcome. Happy hacktober :) |
aakhan1
added a commit
to aakhan1/jsonschema
that referenced
this issue
Oct 27, 2020
…apped error (qri-io#83) this allows the caller get to the underlying error
Done in #85 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What feature or capability would you like?
I would like to gain access the Offset property when a json syntax error occurs so I can report the line and column of the error.
Unfortunately, this results in a panic because the
rs.ValidateBytes
returns a *errors.errorStringpanic: interface conversion: error is *errors.errorString, not *json.SyntaxError
Do you have a proposed solution?
Would it be possible to change the implementation of rs.ValidateBytes to return the error as a wrapped error?
Change the %s to %w? Then I can unwrap the error and get what I need.
Or provide a method on the error object where the original error can be accessed.
Have you considered any alternative solutions or workarounds?
I have implemented my own json.Unmarshal call before calling rs.ValidateBytes, but I feel this adds a performance delay unnecessarily.
The text was updated successfully, but these errors were encountered: