R-alpha: options [--no-*-file] AND --dont-stop-on-error-if-batch

Martin Maechler Martin Maechler <maechler@stat.math.ethz.ch>
Fri, 22 Aug 1997 08:40:25 +0200


>>>>> "Kurt" == Kurt Hornik <hornik@ci.tuwien.ac.at> writes:

>>>>> Thomas Lumley writes:
    >> On Tue, 12 Aug 1997, Martin Maechler wrote:
    MM>  As Thomas Lumley has noted before, the behavior in 'batch mode'
    MM> has changed; namely "Termination upon 'error'".
    MM> 
    MM> I think this is THE good default behavior for "batch mode".
    MM> However 1) for several purposes I'd very much want an option to
    MM> change this default behavior.
    >> Hear, hear!

    MM>  I think it'd be very neat then if options(error.stop = FALSE)
    MM> actually translated all errors [stop(.)] to warnings [warning()].
    MM> 

    >> I'm not convinced.  Being able to make warnings fatal is a good
    >> option, but being able to continue after errors may make no sense.
    >> How do you continue after subscript out of bounds, or argument
    >> missing with no default, or memory exhausted or ...

    >> You may well need to jump back to the top level before it makes
    >> sense to continue.  On the other hand, once at the top level it is
    >> certainly possible to proceed, and so there should be an option to
    >> do it.

    Kurt> There is an obvious trade-off between having a lot of flexibility
    Kurt> and simple too many options :-)

I don't quite see (the ":-)").
The non-expert user just changes options like 'digits' and 'width'
and leaves the others alone.

    Kurt> I am not sure about making warnings fatal.  E.g., code for
    Kurt> chisquare tests usually displays a warning if the approximation
    Kurt> may be bad.  That should never be fatal, though ...
The option exists in S.
It can be very useful for debugging purposes (and that't about it):
If you call a top level function  / a for loop which in certain
circumstances produces warnings that look funny to you, and somehow it's
hard to detect when / why the warnings are produced.

Now you (temporarily) make warnings fatal, and also add something like
options(error = 'dump.frames')  or an "on.exit(browser())".
You will now be able to quickly find and debug the circumstances under
which the warnings were produced.....


    Kurt> Re termination upon error, couldn't there be situations with a
    Kurt> huge simulation loop where one could still do something useful
    Kurt> after e.g. running out of memory?
sure.
As I (and others) said, there are other situations where you just want to
run a source.R file through R and you don't care if somewhere an
unimportant variable is not defined, a graphics device is not open,....

    Kurt> If I unterstand Martin correctly, the extra options() come into
    Kurt> being only because command-line options are hard to port to
    Kurt> point-and-click interfaces ...

This would be the main reason.

I think it's just 'neater' to have many things as part of R core,
instead of part of the OS-interface [to where command line options belong].

On the other hand, currently I (still) can't imagine myself moving off an
Unix based OS. Therefore, I'd be happy with a command line option which
turns off 'stop on error' in batch mode.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-