onelson / jq-rs

Rust crate to provide programmatic access to `jq`.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Handle all relevant jq exit codes

onelson opened this issue · comments

In the main for the jq binary, there are a number of exit codes defined.

enum {
    JQ_OK              =  0,
    JQ_OK_NULL_KIND    = -1, /* exit 0 if --exit-status is not set*/
    JQ_ERROR_SYSTEM    =  2,
    JQ_ERROR_COMPILE   =  3,
    JQ_OK_NO_OUTPUT    = -4, /* exit 0 if --exit-status is not set*/
    JQ_ERROR_UNKNOWN   =  5,
};

Early work on this crate only focused on the happy path, and a couple of error cases (mainly in terms of parsing failures), but it seems there are a number of ways the binary can exit, and we should be modeling these into the error handling.

When we feed the repro jq program shared in #4 to the jq binary, it exits with JQ_ERROR_UNKNOWN, which tells me it would be prudent to audit the jq source for these symbols to learn about how and where these can arise.

It might be that some of these don't apply for our use as a library, but we won't know until we look.

My hope is that by modeling these exit codes in this crate, we'll be adhering to the implicit API contract of libjq. I also expect that as this work is done, we will cover the root cause of #4 in the process.

Recently rewrote (essentially) the internals of this crate, and I have to say the error handling story was improved but also I think I lost the essence of the scheme used by the jq binary.

For instance, there was an is_halted() check added, but it was unclear where this should need to be checked. I think I may be checking for it more often than is really needed.

While working on this, I'll have to pay special attention to where jq puts these checks in the flow of the main() to minimize redundant calls.