-
-
Notifications
You must be signed in to change notification settings - Fork 22
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
Custom exception #115
base: main
Are you sure you want to change the base?
Custom exception #115
Conversation
Codecov ReportAttention: Patch coverage is
📢 Thoughts on this report? Let us know! |
CodSpeed Performance ReportMerging #115 will not alter performanceComparing Summary
|
5e1fed4
to
d5c83a2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Exception type itself looks good, however I'd like to discuss options about how the path is actually built up...
fn set_key_path(&self, err: PythonJsonError) -> PythonJsonError; | ||
} | ||
|
||
pub(crate) trait MaybeBuildPath { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand why you went this way (and map exceptions as they propagate through take_value
), though I wonder if it might be better to have a method on Parser
to work out the .path()
given some index, similar to how we have a method to work out file position. We could probably re-use a lot of the .skip()
implementation to achieve it.
I think that'd be the only way to get json-path-to-errors for iterable parsing without keeping wasted state for the 99.99999% of successful parses.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ye, you're right, we should probably try that, partly because it avoids the parse struct becoming more generic.
#[derive(Debug)] | ||
pub struct PythonJsonError { | ||
pub error: JsonError, | ||
path: Option<Vec<PathItem>>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it worth noting here that the path elements are stored in reverse order? Should we prefer VecDeque
or LinkedList
so that we can insert into the front and avoid potential ordering mistakes?
let v = self._check_take_value(py, peek_first)?; | ||
mut build_path: impl MaybeBuildArrayPath, | ||
) -> PythonJsonResult<()> { | ||
let v = self |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To avoid having to map all over the place, I wonder whether something like
BuildPath::enter_array(|b: &mut BuildPath::ArrayIndex| { /* do stuff */ })
would be more ergonomic, where you call b.set_index()
to update the index, and then enter_array
can be responsible for adding the path to errors inside the closure.
Similar thought for objects.
... but I still wonder if having some parser.path()
method to rebuild the whole path and keep it out of the rest of the control flow is better at the cost of 2x slowdown on errors.
Fix #99