Skip to content

Conversation

samuelcolvin
Copy link
Member

@samuelcolvin samuelcolvin commented Jun 6, 2024

Fix #99

Copy link

codecov bot commented Jun 6, 2024

Codecov Report

Attention: Patch coverage is 84.50000% with 31 lines in your changes missing coverage. Please review.

Files Patch % Lines
crates/jiter/src/errors.rs 24.00% 19 Missing ⚠️
crates/jiter/src/py_error.rs 87.87% 12 Missing ⚠️

📢 Thoughts on this report? Let us know!

Copy link

codspeed-hq bot commented Jun 6, 2024

CodSpeed Performance Report

Merging #115 will not alter performance

Comparing custom-exception (d5c83a2) with main (3b59df6)

Summary

✅ 73 untouched benchmarks

Copy link
Collaborator

@davidhewitt davidhewitt left a 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 {
Copy link
Collaborator

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.

Copy link
Member Author

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>>,
Copy link
Collaborator

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
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Custom Python exception with kind and path
2 participants