-
Notifications
You must be signed in to change notification settings - Fork 61
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
Feature Discussion: More granular skip_exc
in Coalesce
#253
Comments
Have you considered
edit: docs https://glom.readthedocs.io/en/latest/matching.html |
For the exact example you gave: good_data = {"a": {"c": 1}}
bad_data = {"a": [{"c": 1}]} The reason This can be made less ambiguous by using Although, still I think that |
Feature Description
I have found a use-case of glom while programming my project where I believe more granular exception filtering in
Coalesce
may be beneficial. Namely, I may wish thatCoalesce
filter out an exception related to parsing ajson
of expected structure, but still raise when the structure deviates from the expected. I am fully willing to undertake the development of this feature. I am making this issue to start a discussion on such an addition.Example
To explain this better, here is the following example:
The motivation is to benefit from the
default
result fromCoalesce
if ajson
fails to parse, yet not silently allowing possibly buggy code to run where the expected structure of thejson
is completely different from that what is programmed in the glom specification.For example, the expected form of the json is a dict within a dict. Much like:
In this example, running a regular dict look-up produces a
PathAccessError
as such:If fed data in a different form, such as:
The glom look-up still produces a
PathAccessError
, but with a differing exception inside:Currently,
Coalesce
exception filtering is not granular enough to where I am able to filter out the correctly formed exception based on the internalKeyError
, while still raising the malformed one.The internal exception of a
PathAccessError
is accessible via aexc
attribute of the exception object.I am writing this issue to open a discussion on potentially introducing this ability, and how would be a good way to do this.
The text was updated successfully, but these errors were encountered: