Closed surister closed 1 month ago
cc @proddata I'd love your feedback as well as any input on this
I read through it and generally like the idea of not raising an exception. However, I'm not sure about the defaults.
Regarding the "main issue," I don't have a strong opinion as I lack details on the mechanics. If the approach works, though, 👍.
Summary of the changes / Why this is an improvement
Issue #2
This is one of the first pieces required to finish the feature and its only implemented in Python for early feedback/validation.
Main changes of PR:
Throwing antlr4 parse errors as exceptions is now only enabled by
raise_exception
API influenced by DRF ValidatorsDefault behaviour is not to raise an exception, the reason is that it forces clients to try/catch errors, when you already work with CrateDB in the HTTP protocol you are used to check the json response, rather than catching exceptions, this change of behaviour aims to make integrating with this library as similar as possible as with CrateDB.
Implements an
ExceptionCollectorListener
that collects all errors that are caught, (remember that we useparser.statements
, to support running several queries on the frontends, so several errors can happen simultaneously)Adds more verbose errors
The main issue I would like help with the review: <-------------------------------------
Whenever we collect the errors I just add the errors to a list for further processing:
There are a couple of edge cases that I covered but in short, it works reasonable well, even though I'm not a fan of it, maybe you folks way more experience in
antlr4
have an idea?Checklist