On 20/05/2016 10:33 AM, William Dunlap wrote:
The following usage of stopifnot seems reasonable to me and it
would be nice if the 2nd call caused the message 'is.data.frame(df) is
not TRUE'.

f <- function(df) {
    stopifnot(is.data.frame(df), is.integer(df$ID))
    range(df$ID)
}

Yes, that's an example where the proposed behaviour makes sense.  But

stopifnot(is.data.frame(df)); stopifnot(is.integer(df$ID))

isn't that much harder to type, and it already does what you want.

Duncan Murdoch


f(data.frame(ID=4:7))
# [1] 4 7
f(4:7)
# Error in df$ID : $ operator is invalid for atomic vectors


Bill Dunlap
TIBCO Software
wdunlap tibco.com <http://tibco.com>

On Fri, May 20, 2016 at 7:13 AM, Duncan Murdoch
<murdoch.dun...@gmail.com <mailto:murdoch.dun...@gmail.com>> wrote:

    On 20/05/2016 4:44 AM, Vasanth Mohan wrote:

        Hi,

        *stopifnot(FALSE, someOtherExpression)*

        For the above code I expect stopifnot() to always say that
        'FALSE is not
        TRUE' regardless of what someOtherExpression is(It may evaluate
        to TRUE or
        FALSE or throw an error). Is my expectation correct? Is that how
        stopifnot() is supposed to work?

        The present implementation of stopifnot() does not work like
        that. If
        someOtherExpression would throw an error, then stopifnot()
        throws that
        error instead of saying 'FALSE is not TRUE'.

        So, I modified the source code of stopifnot() and now it works
        as I expect
        it to.
        If that is how stopifnot() is supposed to work, then kindly let
        me know how
        I can contribute my solution


    The documentation is unclear on that.  First it implies all
    expressions are evaluated:  "If any of the expressions in ... are
    not all TRUE, stop is called, producing an error message indicating
    the first of the elements of ... which were not true."

    But then the "conceptually equivalent" code acts the way you expected.

    However, it doesn't really make sense to me to put in tests that
    could themselves trigger errors unless you'd be interested in seeing
    those errors, so I don't think I'd change it.

    Duncan Murdoch

    ______________________________________________
    R-help@r-project.org <mailto:R-help@r-project.org> mailing list --
    To UNSUBSCRIBE and more, see
    https://stat.ethz.ch/mailman/listinfo/r-help
    PLEASE do read the posting guide
    http://www.R-project.org/posting-guide.html
    and provide commented, minimal, self-contained, reproducible code.



______________________________________________
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Reply via email to