REBOL3 tracker
  0.9.12 beta
Ticket #0002215 User: anonymous

Project:



Short URL: http://issue.cc/r3/2215
rss
TypeBug Statussubmitted Date7-Apr-2015 00:40
Versionr3 master CategoryUnspecified Submitted byabolka
PlatformAll Severityminor Prioritynormal

Summary When running non-interactively, errors should not HALT to the console but QUIT to the system
Description 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).
Example code
$ 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.

Assigned ton/a Fixed in- Last Update17-Jul-2015 21:44


Comments
(0004634)
abolka
7-Apr-2015 01:05

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.
(0004647)
abolka
17-Jul-2015 21:33

Related discussion on GitHub's rebol/rebol issue tracker: https://github.com/rebol/rebol/issues/246
(0004648)
abolka
17-Jul-2015 21:44

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.

Date User Field Action Change
17-Jul-2015 21:44 abolka Comment : 0004648 Added -
17-Jul-2015 21:33 abolka Comment : 0004647 Added -
7-Apr-2015 01:05 abolka Comment : 0004634 Added -
7-Apr-2015 00:40 abolka Ticket Added -