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

Add location to serialization errors #261

Closed
wyfo opened this issue Nov 27, 2021 · 2 comments · Fixed by #298
Closed

Add location to serialization errors #261

wyfo opened this issue Nov 27, 2021 · 2 comments · Fixed by #298
Labels
enhancement New feature or request
Milestone

Comments

@wyfo
Copy link
Owner

wyfo commented Nov 27, 2021

See #258 for the initial discussion.

@wyfo wyfo added this to the v0.17 milestone Nov 27, 2021
@wyfo
Copy link
Owner Author

wyfo commented Nov 27, 2021

In some cases, e.g. SQLalchemy, serialized objects cannot be easily statically typed checked. Serialization type checking errors should then be enough informative to quickly spot the invalid object.

However, normal use case remains unchecked serialization (for now). Error location tracing must thus have minimal impact on the implementation and the performance. Also, collecting all errors is not considered, as its impact would certainly be too much important.

@wyfo
Copy link
Owner Author

wyfo commented Nov 27, 2021

Two possible implementations are considered first:

  • Add try catch around submethod calls, and add the current error path component to the error caught before reraising it.
  • Add an additional argument to every method for the error path component (with a None default value), and try catch only in the type checking methods.

Both of these methods impact the unchecked implementation, so both implementation should be tried and compared, especially in term of performance.

Also, serialization type checking error should have a custom class (why not deriving TypeError) to store the path and found/expected types (and why not the faulty object, as it could be nice to have for debugging, idk), with a custom __str__ method.

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

Successfully merging a pull request may close this issue.

1 participant