return code should be non-zero if Rel query fails #32
Description
The CLI return code should be non-zero if an error occurs when running Rel code.
% rai --profile tms exec adean-test-db -e adean-test-eng -c "def output = 1+1"
Executing query (adean-test-db/adean-test-eng) readonly=false .. Ok (0.4s)
/:output/Int64
2
% echo $?
0
% rai --profile tms exec adean-test-db -e adean-test-eng -c "blah"
Executing query (adean-test-db/adean-test-eng) readonly=false .. Ok (0.3s)
/:rel/:catalog/:diagnostic/:code/Int64/String
1, UNDEFINED
/:rel/:catalog/:diagnostic/:message/Int64/String
1, `blah` is undefined.
/:rel/:catalog/:diagnostic/:range/:end/:character/Int64/Int64/Int64
1, 1, 4
/:rel/:catalog/:diagnostic/:range/:end/:line/Int64/Int64/Int64
1, 1, 1
/:rel/:catalog/:diagnostic/:range/:start/:character/Int64/Int64/Int64
1, 1, 1
/:rel/:catalog/:diagnostic/:range/:start/:line/Int64/Int64/Int64
1, 1, 1
/:rel/:catalog/:diagnostic/:report/Int64/String
1, 1| blah
^^^^
The problem occurred while compiling declaration `output`:
1| blah
^^^^
/:rel/:catalog/:diagnostic/:severity/Int64/String
1, error
% echo $?
0
%
There are some other inconsistencies with handling failures as well. If a bad profile is specified, a clear error message is displayed:
% rai --profile nonesuch exec adean-test-db -e adean-test-eng -c "def output = 1+1"
Executing query (adean-test-db/adean-test-eng) readonly=false ..
Error: config profile 'nonesuch' not found
% echo $?
1
%
However, if an invalid database is specified then it appears a JSON response from the server is displayed directly to the user.
% rai --profile tms exec adean-test-db -e nonesuch-eng -c "def output = 1+1"
Executing query (adean-test-db/nonesuch-eng) readonly=false .. (0.2s)
400 Bad Request
{"status":"Bad Request","message":"engine not found"}
% echo $?
1
%
That JSON response may be consistent with other CLI commands such as list-databases which typically return data as JSON, but the exec command output is not typically JSON (whether the Rel code is successful or unsuccessful). For exec, I would expect that error messages are extracted from the response and displayed in a more user-friendly format which is independent of the underlying implementation. (But that is separate from this issue request, which is just to properly set the return code.)