https://bz.apache.org/bugzilla/show_bug.cgi?id=70175
--- Comment #3 from Sylwester Lachiewicz <[email protected]> --- Maarten's second comment moves this away from the error/failure distinction, and the code seems to bear that out. In JUnitLauncherTask the forked exit code is handled by a switch on Constants.FORK_EXIT_CODE_*: - TESTS_FAILED (2) and TIMED_OUT (3) both consult failureProperty and haltOnFailure. - EXCEPTION (1) throws a BuildException unconditionally. haltonfailure="false" has no effect on it. - There is no default branch, so any other exit code - a JVM killed by a signal, say - matches nothing and the task carries on as though the fork had succeeded. So a forked JVM that dies either aborts the whole task with no way to opt out, or is ignored silently, depending on which exit code it happens to leave behind. Exit code 1 is ambiguous too: it is Ant's own "the launcher threw" signal and also what a JVM that failed to start leaves behind. If a haltonerror attribute were added, having it gate the EXCEPTION branch and a new default branch the way haltOnFailure gates TESTS_FAILED would cover what Maarten describes, and would keep the AssertionError question in 69687 separate. Defaulting it to true would preserve today's behaviour. Happy to put a patch together if that shape sounds right. This comment was created with AI assistance. -- You are receiving this mail because: You are the assignee for the bug.
