Error exit code on success

[Susana Hahn]

Hi! I am getting an exit status code of 1 for sucess. Is this intended? I am running your example:

% Probabilistic facts:
0.5::heads1.
0.6::heads2.

% Rules:
twoHeads :- heads1, heads2.

% Queries:
query(heads1).
query(heads2).
query(twoHeads).

And just running:

>>> problog coin.pl -v
[INFO] Output level: INFO
[INFO] Propagating evidence: 0.0000s
[INFO] Grounding: 0.0016s
[INFO] Cycle breaking: 0.0001s
[INFO] Clark's completion: 0.0000s
[INFO] DSharp compilation: 0.6023s
[INFO] Total time: 0.6084s
  heads1:	0.5
  heads2:	0.6
twoHeads:	0.3

>>> echo $?
1

[Mezzenilium]

You are right, Problog always seems to end with the code: 1, whether the source of the interpreted program is correct or flawed.
I noticed this on my local version of Problog installed on a Linux PC.

Program with error :

(False, ParseError('% Probabilistic facts:\n0.5::heads1.\n0.6::heads2.\n\n% Rules:\ntwoHeads :- heads1, heads2\n\n%    Queries:\nquery(heads1).\nquery(heads2).\nquery(twoHeads).\n', 'Expected binary operator', 98))
------------------
(program exited with code: 1)
Press return to continue

Program without error :

(True, {heads2: 0.6000000000000001, heads1: 0.5000000000000001, twoHeads: 0.30000000000000004})
 ------------------
(program exited with code: 1)
Press return to continue

The convention that a function should return 0 when its execution has been nominal has its origin in the C language. Indeed Problog seems to not respect this convention of behaviour.

In fact even when I intentionally introduced a syntax error into the code of the program written in Problog, the behaviour of the Problog interpreter was correct because it detected and reported the presence of this error.
Otherwise, I have not yet encountered a case where Problog does not do what it is supposed to do.

[Vincent]

This should be fixed in version v2.2.3 for the probability task (relevant commit b719042).

For the other tasks (mpe, sample, ...), it is still on the internal to do list.

[Stephen Demjanenko]

Instead of having the CLI script call sys.exist(main()), propagating anything main() returns as the exit code, it may be easier to maintain if sys.exit is called with a non-zero code in an except block. If one wants to control the non-zero code, then perhaps one can raise a specific class of exception with the desired code set.