Skip to content
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

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open

Custom exception #115

wants to merge 4 commits into from

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