For debug purposes or certain production scenarios, users may benefit from a -stoponerror CLI flag that would cause a running query to exit entirely (and probably cause super to return a non-zero exit code) in reaction to error values that appear during the running of a query.
Details
At the time this issue is being opened, super is at commit 508a543.
An advisor has recently bumped into a desire for this functionality while prototyping his "paged API" use case, though many of us on the project team have envisioned the benefits of this as well.
SuperSQL has its functions like is_error and has_error that allow a query to react to the presence of error values that appear as a query is executing. However, at the moment this only allows for things like applying conditional logic while the query continues to run, and a user may not want to burn time letting an input stream be processed to completion after some error condition has been met. Fully instrumenting a query at every location an error value may appear also would come with a cost, which could be seen as a significant part of a debug effort early in the development of a sophisticated query. Therefore being able to invoke something like a -stoponerror flag could act as a blunt way for a user to weed out error conditions in such situations and/or continue using in production scenarios when errors can never be tolerated.
This feature overlaps somewhat in functionality with the one proposed in #5298, which seeks "early exit" as something that can be triggered by logic inside the query. Contrasting the two ideas:
|
Proposed #5298 exit operator |
Proposed -stoponerror |
| Where it's specified |
a point in the pipeline you chose |
outside the query entirely |
| What triggers it |
a Boolean expression you wrote |
any error value, including ones you never anticipated |
| What it stops |
the current branch (and presumably the whole process if all branches have exited) |
the whole process |
Design consideration
To halt when any error value is generated anywhere during the running of a query might be too blunt, since some queries might already contain logic to intentionally detect and react to errors. Therefore if we wanted to design this first with a single mission, perhaps we could tie it to just error values that reach the output writer. That said, with super in its current form, error values sometimes appear and get swallowed in ways that are difficult to notice (see #6696 for instance) so until we have confidence that errors always propagate reliably to output unless explicitly handled, perhaps the flag could offer modes like output and all.
For debug purposes or certain production scenarios, users may benefit from a
-stoponerrorCLI flag that would cause a running query to exit entirely (and probably causesuperto return a non-zero exit code) in reaction toerrorvalues that appear during the running of a query.Details
At the time this issue is being opened, super is at commit 508a543.
An advisor has recently bumped into a desire for this functionality while prototyping his "paged API" use case, though many of us on the project team have envisioned the benefits of this as well.
SuperSQL has its functions like
is_errorandhas_errorthat allow a query to react to the presence oferrorvalues that appear as a query is executing. However, at the moment this only allows for things like applying conditional logic while the query continues to run, and a user may not want to burn time letting an input stream be processed to completion after some error condition has been met. Fully instrumenting a query at every location anerrorvalue may appear also would come with a cost, which could be seen as a significant part of a debug effort early in the development of a sophisticated query. Therefore being able to invoke something like a-stoponerrorflag could act as a blunt way for a user to weed out error conditions in such situations and/or continue using in production scenarios when errors can never be tolerated.This feature overlaps somewhat in functionality with the one proposed in #5298, which seeks "early exit" as something that can be triggered by logic inside the query. Contrasting the two ideas:
exitoperator-stoponerrorerrorvalue, including ones you never anticipatedDesign consideration
To halt when any
errorvalue is generated anywhere during the running of a query might be too blunt, since some queries might already contain logic to intentionally detect and react to errors. Therefore if we wanted to design this first with a single mission, perhaps we could tie it to justerrorvalues that reach the output writer. That said, withsuperin its current form,errorvalues sometimes appear and get swallowed in ways that are difficult to notice (see #6696 for instance) so until we have confidence that errors always propagate reliably to output unless explicitly handled, perhaps the flag could offer modes likeoutputandall.