-
Notifications
You must be signed in to change notification settings - Fork 13
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
Plist deserialization: investigate better error reporting #196
Comments
We now have an error chain so at least we know which file blows up. Line information in quick_xml and plist seems harder to come by? |
I don't think we can do something for a v1.0? Eventually we need to take our found plist problems upstream or make a custom plist handler. |
I think as long as this is just about how errors are represented/printed it's okay to worry about after 1.0. :) |
I think it is, or at least I hope so. If we implement our own plist parser crate (on top tof quick_xml), we need to change the publicly exposed error types, though. That's a vague "if" though. Taking this off of 1.0 for now, there's no shame in a 2.0 :) |
I just had someone edit a contents.plist file and forgetting to delete the
<value>
and the<key>
. The returned error wasNot very helpful. norad should take care to bubble up the file in question and ideally the location of the 💥.
The text was updated successfully, but these errors were encountered: