-
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
Match report-many-errors for APIs and unit tests #244
Comments
Actually, we don't really need to resume -- the handlers could be adjusted. def glom():
for child in child_specs:
try:
glom(child)
except GlomError as exc:
if not scope[MULTIERROR]:
raise
errors.append(exc)
if errors:
raise MultiError(errors) |
Then we just need a MultiError that's able to capture the scope for each of it's sub-errors, and the data stack machinery needs to know what to do with a MultiError to print it nicely. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is something we've discussed before, but for unit tests and APIs it's very convenient to keep going and find as many errors as possible rather than stopping on the first error.
Some of the challenges with this:
Data-stack error reporting is really oriented towards only reporting a single error (this could be addressed by either printing them sequentially, or printing up to the last-common-spec and then printing the branch for each exception separately).
I'm imagining Match objects will have a kwarg "multi-error" or something. This will cause GlomErrors to be caught and execution to resume. A challenge with this is how to resume execution. Probably this means making the error stack a read/write data structure rather than write only. So that participating glom handlers will be able to "find their place" in the error stack when asked to resume. (The most important is that dict handlers know how to resume execution on the next key, and that list handlers know how to resume execution on the next item of the list.)
The algorithm for resuming execution would be something like this:
Find the leaf-most spec which knows how to resume execution; replace the spec with a version that is resuming from that spot.
The text was updated successfully, but these errors were encountered: