When running non-interactively, errors should not HALT to the console but QUIT to the system

[rebolbot]

Submitted by: abolka

When you run rebol3 some-script.reb and %some-script.reb causes an uncaught Rebol error, the Rebol interpreter halts to the console, instead of quitting to the operating system. See the example code for an illustration of the problem.

The current "halt-on-error" behaviour is extremely annoying when executing Rebol scripts unsupervised (servers, batch processes, cron jobs, etc). It makes general "process has crashed" monitors useless, because from the outside a crashed script of course looks like it is still running. One workaround I have had to use for years is to use wrappers running echo quit/now | rebol3 some-script.reb.

Unfortunately, this issue also ties into personal preference and usage patterns. On Windows, when the Rebol interpreter is associated with .reb so that a script can be executed by simply double-clicking, halting to the console may well be what is expected -- as you may not see the error at all, otherwise.

Therefore, as a first fix I propose to introduce a new command-line option: --on-error [halt|quit]. Current behaviour would of course equal --on-error halt, whereas --on-error quit would return to the operating system when an error occurs. Further, --on-error quit must use an adequate process exit code to indicate that an error occurred -- on Linux, OS X, and Windows that'd mean returning a non-zero exit code.

With the command-line option in place, we can then discuss which behaviour should be the default. Ideally, we'd do a better job with choosing a good default depending on the actual environment (such as automatically choosing halt-on-error when a script is run because of double-clicking in Windows; if that is possible at all).

One final remark: when DO-ing a script from the Rebol console an error should of course continue to return back to the console, and not kill the console (irrespective of the --on-error option).

$ echo "REBOL [] 1 / 0" > div0.reb
$ rebol3 div0.reb
** Math error: attempt to divide by zero
** Where: / do either either either -apply-
** Near: / 0

>>  ;; Here's the problem, if you want a crash in the script to
    ;; also kill the script-running Rebol process.

^{CC - Data [ Version: r3 master Type: Bug Platform: All Category: Unspecified Reproduce: Always Fixed-in:none ]}

[rebolbot]

Submitted by: abolka

A related improvement is to print the error message (of the error which causes the process to quit) to the standard error stream -- that's already tracked by #1862.

[rebolbot]

Submitted by: abolka

Related discussion on GitHub's rebol/rebol issue tracker: https://github.com/rebol/rebol/issues/246

[rebolbot]

Submitted by: abolka

As a first approximation towards a solution, I'd suggest an "on-error" command-line flag. "--on-error=halt" would reproduce the current behaviour, "--on-error=quit" would result in a sane behaviour typical command-line script execution and non-interactive execution. Further, I'd suggest exposing that option also via system/options, so that its default can be also set via %user.r. Finally, we should start thinking about switching the default from current "halt" to "quit".

Eventually, we could also introduce as a default a somewhat fancy trick as suggested by @HostileFork in the discussion on Github referenced above (let's call it "wait-on-error"): as a default, on error, wait for a few seconds to give an alert user a chance to halt into a debug session; if no user interaction occurs within those few seconds, quit.

[Oldes]

Not exactly what @earl initially requested, but I believe it is better, than what was original functionality: https://github.com/Oldes/Rebol3/commit/61c138334d9fd93ca5760fdf685080f285251193

[hostilefork]

but I believe it is better, than what was original functionality

As mentioned I had this idea and implemented it, though people didn't particularly like it as a default. There was enough complaint that I made quitting the default, since it seemed to their feeling the solution was worse than the problem.

It might need more study to find out exactly what it was that people didn't like.