[Rd] Suppress specific warnings
Hello, is there a convenient way to suppress only *specific* warnings? (I know about ?suppressWarnings) I depend on another package, from which I want to suppress only some warnings, but not others. Felix __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suppress specific warnings
On 13-04-18 7:31 AM, Felix Schönbrodt wrote:
Hello,
is there a convenient way to suppress only *specific* warnings? (I know about
?suppressWarnings)
I depend on another package, from which I want to suppress only some warnings,
but not others.
This is difficult in most cases, because most packages don't give enough
information to distinguish among their warnings. You could probably do
it based on the message as follows, but the test won't work if someone
is running in a locale where the warning message has been translated to
a different language:
x - 1:10
x + 1:3 # gives the warning:
In x + 1:3 :
longer object length is not a multiple of shorter object length
To suppress just this one, try this:
withCallingHandlers(x + 1:3,
warning=function(w) {
if (grepl(longer object length, w$message))
invokeRestart(muffleWarning)
} )
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suppress specific warnings
On 04/18/2013 05:57 AM, Duncan Murdoch wrote:
On 13-04-18 7:31 AM, Felix Schönbrodt wrote:
Hello,
is there a convenient way to suppress only *specific* warnings? (I know about
?suppressWarnings)
I depend on another package, from which I want to suppress only some warnings,
but not others.
This is difficult in most cases, because most packages don't give enough
information to distinguish among their warnings. You could probably do it based
maybe useful to make the point that it isn't hard to for the package you depend
on to signal different types of warnings
w = simpleWarning(curves ahead)
class(w) = c(curves, class(w))
warning(w)
more below...
on the message as follows, but the test won't work if someone is running in a
locale where the warning message has been translated to a different language:
x - 1:10
x + 1:3 # gives the warning:
In x + 1:3 :
longer object length is not a multiple of shorter object length
To suppress just this one, try this:
withCallingHandlers(x + 1:3,
warning=function(w) {
if (grepl(longer object length, w$message))
invokeRestart(muffleWarning)
} )
...which are then caught as
withCallingHandlers({
warning(w) # 'curves'; caught
warning(another warning)
}, curves=function(w) invokeRestart(muffleWarning))
The tricky part is to come up with an appropriate scheme for classifying
warnings.
Martin Morgan
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M1 B861
Phone: (206) 667-2793
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suppress specific warnings
For my logging package (futile.logger) any log statements coming from a package
are assigned to a package namespace. This way you have control of log messages
at a package level (e.g. I can set the default log threshold to DEBUG, while
package 'A' has a log threshold of WARN).
I seems a hierarchical namespace facility would work for the below case as
well.
On Apr 18, 2013, at 9:29 AM, Martin Morgan mtmor...@fhcrc.org wrote:
To suppress just this one, try this:
withCallingHandlers(x + 1:3,
warning=function(w) {
if (grepl(longer object length, w$message))
invokeRestart(muffleWarning)
} )
...which are then caught as
withCallingHandlers({
warning(w) # 'curves'; caught
warning(another warning)
}, curves=function(w) invokeRestart(muffleWarning))
The tricky part is to come up with an appropriate scheme for classifying
warnings.
•
Brian Lee Yung Rowe
917 496 4583
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] suppress *specific* warnings?
Duncan Murdoch murdoch.dun...@gmail.com
on Thu, 25 Oct 2012 06:51:25 -0400 writes:
On 12-10-25 5:28 AM, Martin Maechler wrote:
Sorry guys, for coming late,
but *please* don't go there.
I've been there years ago,
and found later why the approach is flawed by design :
Internationalization / Localization:
- If the warning comes from a standard R function,
the warning is almost surely different in a (say) German
locale, and your pattern won't be detected.
- Ditto if from a recommended package.
- If it is a warning that is not translated then it may be that
it is just not *YET* translated.
I think the other Martin's suggestion addressed this: he matched the
translated message, not the English original.
Duncan Murdoch
Well, I don't think I understand.
Of course you can only match the message that warning() or
error() {or rather tryCatch() ,...} produces.
But you cannot guarantee nor know (for sure) if that message is 'original'
or translated.
cannot, because AFAIK
we cannot guarantee Sys.setlocale() is obeyed platform
independently:
You would have to query the current and save that, set it to C, get the
message, and then reset the locale to the previously saved one.
And these do not work reliably, on some platforms, AFAIK and
read our documentation.
Martin
The really dangerous thing about matching error / warning
messages -- I had done it in the past with the error message I
caught via tryCatch() --
is that
- in your tests the code will work perfectly.
- on CRAN the code will work perfectly, as they also use
the English (or C) locale.
So, by doing this you are distributing code that almost always
works ... in your environment if you are US, UK or similarly
based.
Indeed, a *really* dangerous practice.
Martin Maechler, ETH Zurich
Martin Morgan mtmor...@fhcrc.org
on Tue, 23 Oct 2012 05:28:48 -0700 writes:
On 10/22/2012 09:57 AM, luke-tier...@uiowa.edu wrote:
On Sun, 21 Oct 2012, Martin Morgan wrote:
On 10/21/2012 12:28 PM, Ben Bolker wrote:
Not desperately important, but nice to have and possibly of use to
others, is the ability to suppress specific warnings rather than
suppressing warnings indiscriminately. I often know of a specific
warning that I want to ignore (because I know that's it's a false
positive/ignorable), but the current design of suppressWarnings()
forces
me to ignore *any* warnings coming from the expression.
I started to write a new version that would check and, if supplied
with a regular expression, would only block matching warnings and
otherwise would produce the warnings as usual, but I don't quite
know
enough about what I'm doing: see ??? in expression below.
Can anyone help, or suggest pointers to relevant
examples/documentation (I've looked at demo(error.catching), which
isn't
helping me ... ?)
suppressWarnings2 - function(expr,regex=NULL) {
opts - options(warn = -1)
on.exit(options(opts))
I'm not really sure what the options(warn=-1) is doing there, maybe
its for
efficiency to avoid generating a warning message (as distinct from
signalling
The sources in srs/library/base/conditions.R have
suppressWarnings - function(expr) {
ops - options(warn = -1) ## FIXME: temporary hack until R_tryEval
on.exit(options(ops)) ## calls are removed from methods code
withCallingHandlers(expr,
warning=function(w)
invokeRestart(muffleWarning))
}
I uspect we have still not entirely eliminated R_tryEval in this
context
but I'm not sure. Will check when I get a chance.
a warning). I think you're after something like
suppressWarnings2 -
function(expr, regex=character())
{
withCallingHandlers(expr, warning=function(w) {
if (length(regex) == 1 length(grep(regex, conditionMessage(w {
invokeRestart(muffleWarning)
}
})
}
A problem with using expression matching is of course that this fails
with internationalized messages. Ideally warnings should be signaled
as
warning conditions of a particular class, and that class can be used
to discriminate. Unfortunately very few warnings are designed this
way.
Probably specific messages, rather than patterns, would be handled and
then
suppressWarnings2 - function(expr, messages = character())
{
opts - options(warn = -1)
on.exit(options(ops))
withCallingHandlers(expr, warning=function(w) {
if (conditionMessage(w) %in% messages)
invokeRestart(muffleWarning)
})
}
gives one the illusion of speaking many
Re: [Rd] suppress *specific* warnings?
On Oct 26, 2012, at 11:17 , Martin Maechler wrote:
Duncan Murdoch murdoch.dun...@gmail.com
on Thu, 25 Oct 2012 06:51:25 -0400 writes:
On 12-10-25 5:28 AM, Martin Maechler wrote:
Sorry guys, for coming late,
but *please* don't go there.
I've been there years ago,
and found later why the approach is flawed by design :
Internationalization / Localization:
- If the warning comes from a standard R function,
the warning is almost surely different in a (say) German
locale, and your pattern won't be detected.
- Ditto if from a recommended package.
- If it is a warning that is not translated then it may be that
it is just not *YET* translated.
I think the other Martin's suggestion addressed this: he matched the
translated message, not the English original.
Duncan Murdoch
Well, I don't think I understand.
Of course you can only match the message that warning() or
error() {or rather tryCatch() ,...} produces.
But you cannot guarantee nor know (for sure) if that message is 'original'
or translated.
cannot, because AFAIK
we cannot guarantee Sys.setlocale() is obeyed platform
independently:
You would have to query the current and save that, set it to C, get the
message, and then reset the locale to the previously saved one.
And these do not work reliably, on some platforms, AFAIK and
read our documentation.
I think the point was to use gettext() on the pattern-to-match. If the warning
is translated, so would this be. The main limitations would seem to be that you
have to be d*mn sure to get the spelling right and, presumably, it only works
with straight string translations, not variant forms like
msgid found %d fatal error
msgid_plural found %d fatal errors
msgstr[0] s'ha trobat %d error fatal
msgstr[1] s'han trobat %d errors fatals
Martin
The really dangerous thing about matching error / warning
messages -- I had done it in the past with the error message I
caught via tryCatch() --
is that
- in your tests the code will work perfectly.
- on CRAN the code will work perfectly, as they also use
the English (or C) locale.
So, by doing this you are distributing code that almost always
works ... in your environment if you are US, UK or similarly
based.
Indeed, a *really* dangerous practice.
Martin Maechler, ETH Zurich
Martin Morgan mtmor...@fhcrc.org
on Tue, 23 Oct 2012 05:28:48 -0700 writes:
On 10/22/2012 09:57 AM, luke-tier...@uiowa.edu wrote:
On Sun, 21 Oct 2012, Martin Morgan wrote:
On 10/21/2012 12:28 PM, Ben Bolker wrote:
Not desperately important, but nice to have and possibly of use to
others, is the ability to suppress specific warnings rather than
suppressing warnings indiscriminately. I often know of a specific
warning that I want to ignore (because I know that's it's a false
positive/ignorable), but the current design of suppressWarnings() forces
me to ignore *any* warnings coming from the expression.
I started to write a new version that would check and, if supplied
with a regular expression, would only block matching warnings and
otherwise would produce the warnings as usual, but I don't quite know
enough about what I'm doing: see ??? in expression below.
Can anyone help, or suggest pointers to relevant
examples/documentation (I've looked at demo(error.catching), which isn't
helping me ... ?)
suppressWarnings2 - function(expr,regex=NULL) {
opts - options(warn = -1)
on.exit(options(opts))
I'm not really sure what the options(warn=-1) is doing there, maybe its
for
efficiency to avoid generating a warning message (as distinct from
signalling
The sources in srs/library/base/conditions.R have
suppressWarnings - function(expr) {
ops - options(warn = -1) ## FIXME: temporary hack until R_tryEval
on.exit(options(ops)) ## calls are removed from methods code
withCallingHandlers(expr,
warning=function(w)
invokeRestart(muffleWarning))
}
I uspect we have still not entirely eliminated R_tryEval in this context
but I'm not sure. Will check when I get a chance.
a warning). I think you're after something like
suppressWarnings2 -
function(expr, regex=character())
{
withCallingHandlers(expr, warning=function(w) {
if (length(regex) == 1 length(grep(regex, conditionMessage(w {
invokeRestart(muffleWarning)
}
})
}
A problem with using expression matching is of course that this fails
with internationalized messages. Ideally warnings should be signaled as
warning conditions of a particular class, and that class can be used
to discriminate. Unfortunately very few warnings are designed this way.
Probably specific messages, rather than patterns, would be handled and then
suppressWarnings2 - function(expr, messages = character())
{
opts - options(warn = -1)
on.exit(options(ops))
withCallingHandlers(expr, warning=function(w) {
if (conditionMessage(w) %in% messages)
invokeRestart(muffleWarning)
})
}
gives one the illusion
Re: [Rd] suppress *specific* warnings?
On 26/10/2012 12:04, peter dalgaard wrote:
On Oct 26, 2012, at 11:17 , Martin Maechler wrote:
Duncan Murdoch murdoch.dun...@gmail.com
on Thu, 25 Oct 2012 06:51:25 -0400 writes:
On 12-10-25 5:28 AM, Martin Maechler wrote:
Sorry guys, for coming late,
but *please* don't go there.
I've been there years ago,
and found later why the approach is flawed by design :
Internationalization / Localization:
- If the warning comes from a standard R function,
the warning is almost surely different in a (say) German
locale, and your pattern won't be detected.
- Ditto if from a recommended package.
- If it is a warning that is not translated then it may be that
it is just not *YET* translated.
I think the other Martin's suggestion addressed this: he matched the
translated message, not the English original.
Duncan Murdoch
Well, I don't think I understand.
Of course you can only match the message that warning() or
error() {or rather tryCatch() ,...} produces.
But you cannot guarantee nor know (for sure) if that message is 'original'
or translated.
cannot, because AFAIK
we cannot guarantee Sys.setlocale() is obeyed platform
independently:
You would have to query the current and save that, set it to C, get the
message, and then reset the locale to the previously saved one.
And these do not work reliably, on some platforms, AFAIK and
read our documentation.
I think the point was to use gettext() on the pattern-to-match. If
the warning is translated, so would this be. The main limitations would seem
to be that you have to be d*mn sure to get the spelling right and,
presumably, it only works with straight string translations, not variant
forms like
msgid found %d fatal error
msgid_plural found %d fatal errors
msgstr[0] s'ha trobat %d error fatal
msgstr[1] s'han trobat %d errors fatals
Yes: you also need to get the domain right (and it would be unsafe not
to specify it on the gettext() call). And C-level messages do move
between domains; for example between R 2.15.x and R-devel most of the
graphics ones have moved from 'R' to 'graphics'.
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] suppress *specific* warnings?
Sorry guys, for coming late,
but *please* don't go there.
I've been there years ago,
and found later why the approach is flawed by design :
Internationalization / Localization:
- If the warning comes from a standard R function,
the warning is almost surely different in a (say) German
locale, and your pattern won't be detected.
- Ditto if from a recommended package.
- If it is a warning that is not translated then it may be that
it is just not *YET* translated.
The really dangerous thing about matching error / warning
messages -- I had done it in the past with the error message I
caught via tryCatch() --
is that
- in your tests the code will work perfectly.
- on CRAN the code will work perfectly, as they also use
the English (or C) locale.
So, by doing this you are distributing code that almost always
works ... in your environment if you are US, UK or similarly
based.
Indeed, a *really* dangerous practice.
Martin Maechler, ETH Zurich
Martin Morgan mtmor...@fhcrc.org
on Tue, 23 Oct 2012 05:28:48 -0700 writes:
On 10/22/2012 09:57 AM, luke-tier...@uiowa.edu wrote:
On Sun, 21 Oct 2012, Martin Morgan wrote:
On 10/21/2012 12:28 PM, Ben Bolker wrote:
Not desperately important, but nice to have and possibly of use to
others, is the ability to suppress specific warnings rather than
suppressing warnings indiscriminately. I often know of a specific
warning that I want to ignore (because I know that's it's a false
positive/ignorable), but the current design of suppressWarnings()
forces
me to ignore *any* warnings coming from the expression.
I started to write a new version that would check and, if supplied
with a regular expression, would only block matching warnings and
otherwise would produce the warnings as usual, but I don't quite know
enough about what I'm doing: see ??? in expression below.
Can anyone help, or suggest pointers to relevant
examples/documentation (I've looked at demo(error.catching), which
isn't
helping me ... ?)
suppressWarnings2 - function(expr,regex=NULL) {
opts - options(warn = -1)
on.exit(options(opts))
I'm not really sure what the options(warn=-1) is doing there, maybe its
for
efficiency to avoid generating a warning message (as distinct from
signalling
The sources in srs/library/base/conditions.R have
suppressWarnings - function(expr) {
ops - options(warn = -1) ## FIXME: temporary hack until R_tryEval
on.exit(options(ops)) ## calls are removed from methods code
withCallingHandlers(expr,
warning=function(w)
invokeRestart(muffleWarning))
}
I uspect we have still not entirely eliminated R_tryEval in this context
but I'm not sure. Will check when I get a chance.
a warning). I think you're after something like
suppressWarnings2 -
function(expr, regex=character())
{
withCallingHandlers(expr, warning=function(w) {
if (length(regex) == 1 length(grep(regex, conditionMessage(w {
invokeRestart(muffleWarning)
}
})
}
A problem with using expression matching is of course that this fails
with internationalized messages. Ideally warnings should be signaled as
warning conditions of a particular class, and that class can be used
to discriminate. Unfortunately very few warnings are designed this way.
Probably specific messages, rather than patterns, would be handled and
then
suppressWarnings2 - function(expr, messages = character())
{
opts - options(warn = -1)
on.exit(options(ops))
withCallingHandlers(expr, warning=function(w) {
if (conditionMessage(w) %in% messages)
invokeRestart(muffleWarning)
})
}
gives one the illusion of speaking many languages
suppressWarnings2(log(-1), gettext(NaNs introduced, domain=R))
Martin
Best,
luke
If the restart isn't invoked, then the next handler is called and the
warning
is handled as normal. So with
f - function() {
warning(oops)
2
}
there is
suppressWarnings2(f())
[1] 2
Warning message:
In f() : oops
suppressWarnings2(f(), oops)
[1] 2
For your own code I think a better strategy is to create a sub-class of
warnings that can be handled differently
mywarn -
function(..., call.=TRUE, immediate.=FALSE, domain=NULL)
{
msg - .makeMessage(..., domain=domain, appendLF=FALSE)
call - NULL
if (call.)
call - sys.call(1L)
class - c(silencable, simpleWarning, warning, condition)
cond - structure(list(message=msg, call=call), class=class)
warning(cond)
}
suppressWarnings3 -
function(expr)
{
withCallingHandlers(expr, silencable=function(w) {
Re: [Rd] suppress *specific* warnings?
On 12-10-25 5:28 AM, Martin Maechler wrote:
Sorry guys, for coming late,
but *please* don't go there.
I've been there years ago,
and found later why the approach is flawed by design :
Internationalization / Localization:
- If the warning comes from a standard R function,
the warning is almost surely different in a (say) German
locale, and your pattern won't be detected.
- Ditto if from a recommended package.
- If it is a warning that is not translated then it may be that
it is just not *YET* translated.
I think the other Martin's suggestion addressed this: he matched the
translated message, not the English original.
Duncan Murdoch
The really dangerous thing about matching error / warning
messages -- I had done it in the past with the error message I
caught via tryCatch() --
is that
- in your tests the code will work perfectly.
- on CRAN the code will work perfectly, as they also use
the English (or C) locale.
So, by doing this you are distributing code that almost always
works ... in your environment if you are US, UK or similarly
based.
Indeed, a *really* dangerous practice.
Martin Maechler, ETH Zurich
Martin Morgan mtmor...@fhcrc.org
on Tue, 23 Oct 2012 05:28:48 -0700 writes:
On 10/22/2012 09:57 AM, luke-tier...@uiowa.edu wrote:
On Sun, 21 Oct 2012, Martin Morgan wrote:
On 10/21/2012 12:28 PM, Ben Bolker wrote:
Not desperately important, but nice to have and possibly of use to
others, is the ability to suppress specific warnings rather than
suppressing warnings indiscriminately. I often know of a specific
warning that I want to ignore (because I know that's it's a false
positive/ignorable), but the current design of suppressWarnings()
forces
me to ignore *any* warnings coming from the expression.
I started to write a new version that would check and, if supplied
with a regular expression, would only block matching warnings and
otherwise would produce the warnings as usual, but I don't quite know
enough about what I'm doing: see ??? in expression below.
Can anyone help, or suggest pointers to relevant
examples/documentation (I've looked at demo(error.catching), which
isn't
helping me ... ?)
suppressWarnings2 - function(expr,regex=NULL) {
opts - options(warn = -1)
on.exit(options(opts))
I'm not really sure what the options(warn=-1) is doing there, maybe
its for
efficiency to avoid generating a warning message (as distinct from
signalling
The sources in srs/library/base/conditions.R have
suppressWarnings - function(expr) {
ops - options(warn = -1) ## FIXME: temporary hack until R_tryEval
on.exit(options(ops)) ## calls are removed from methods code
withCallingHandlers(expr,
warning=function(w)
invokeRestart(muffleWarning))
}
I uspect we have still not entirely eliminated R_tryEval in this context
but I'm not sure. Will check when I get a chance.
a warning). I think you're after something like
suppressWarnings2 -
function(expr, regex=character())
{
withCallingHandlers(expr, warning=function(w) {
if (length(regex) == 1 length(grep(regex, conditionMessage(w {
invokeRestart(muffleWarning)
}
})
}
A problem with using expression matching is of course that this fails
with internationalized messages. Ideally warnings should be signaled as
warning conditions of a particular class, and that class can be used
to discriminate. Unfortunately very few warnings are designed this way.
Probably specific messages, rather than patterns, would be handled and
then
suppressWarnings2 - function(expr, messages = character())
{
opts - options(warn = -1)
on.exit(options(ops))
withCallingHandlers(expr, warning=function(w) {
if (conditionMessage(w) %in% messages)
invokeRestart(muffleWarning)
})
}
gives one the illusion of speaking many languages
suppressWarnings2(log(-1), gettext(NaNs introduced, domain=R))
Martin
Best,
luke
If the restart isn't invoked, then the next handler is called and the
warning
is handled as normal. So with
f - function() {
warning(oops)
2
}
there is
suppressWarnings2(f())
[1] 2
Warning message:
In f() : oops
suppressWarnings2(f(), oops)
[1] 2
For your own code I think a better strategy is to create a sub-class of
warnings that can be handled differently
mywarn -
function(..., call.=TRUE, immediate.=FALSE, domain=NULL)
{
msg - .makeMessage(..., domain=domain, appendLF=FALSE)
call - NULL
if (call.)
call - sys.call(1L)
class -
Re: [Rd] suppress *specific* warnings?
On Sun, 21 Oct 2012, Martin Morgan wrote:
On 10/21/2012 12:28 PM, Ben Bolker wrote:
Not desperately important, but nice to have and possibly of use to
others, is the ability to suppress specific warnings rather than
suppressing warnings indiscriminately. I often know of a specific
warning that I want to ignore (because I know that's it's a false
positive/ignorable), but the current design of suppressWarnings() forces
me to ignore *any* warnings coming from the expression.
I started to write a new version that would check and, if supplied
with a regular expression, would only block matching warnings and
otherwise would produce the warnings as usual, but I don't quite know
enough about what I'm doing: see ??? in expression below.
Can anyone help, or suggest pointers to relevant
examples/documentation (I've looked at demo(error.catching), which isn't
helping me ... ?)
suppressWarnings2 - function(expr,regex=NULL) {
opts - options(warn = -1)
on.exit(options(opts))
I'm not really sure what the options(warn=-1) is doing there, maybe its for
efficiency to avoid generating a warning message (as distinct from signalling
The sources in srs/library/base/conditions.R have
suppressWarnings - function(expr) {
ops - options(warn = -1) ## FIXME: temporary hack until R_tryEval
on.exit(options(ops)) ## calls are removed from methods code
withCallingHandlers(expr,
warning=function(w)
invokeRestart(muffleWarning))
}
I uspect we have still not entirely eliminated R_tryEval in this context
but I'm not sure. Will check when I get a chance.
a warning). I think you're after something like
suppressWarnings2 -
function(expr, regex=character())
{
withCallingHandlers(expr, warning=function(w) {
if (length(regex) == 1 length(grep(regex, conditionMessage(w
{
invokeRestart(muffleWarning)
}
})
}
A problem with using expression matching is of course that this fails
with internationalized messages. Ideally warnings should be signaled as
warning conditions of a particular class, and that class can be used
to discriminate. Unfortunately very few warnings are designed this way.
Best,
luke
If the restart isn't invoked, then the next handler is called and the
warning is handled as normal. So with
f - function() {
warning(oops)
2
}
there is
suppressWarnings2(f())
[1] 2
Warning message:
In f() : oops
suppressWarnings2(f(), oops)
[1] 2
For your own code I think a better strategy is to create a sub-class of
warnings that can be handled differently
mywarn -
function(..., call.=TRUE, immediate.=FALSE, domain=NULL)
{
msg - .makeMessage(..., domain=domain, appendLF=FALSE)
call - NULL
if (call.)
call - sys.call(1L)
class - c(silencable, simpleWarning, warning, condition)
cond - structure(list(message=msg, call=call), class=class)
warning(cond)
}
suppressWarnings3 -
function(expr)
{
withCallingHandlers(expr, silencable=function(w) {
invokeRestart(muffleWarning)
})
}
then with
g - function() {
mywarn(oops)
3
}
suppressWarnings3(f())
[1] 2
Warning message:
In f() : oops
g()
[1] 3
Warning message:
In g() : oops
suppressWarnings3(g())
[1] 3
withCallingHandlers(expr, warning = function(w) {
## browser()
if (is.null(regex) || grepl(w[[message]],regex)) {
invokeRestart(muffleWarning)
} else {
## ? what do I here to get the warning issued?
## browser()
## computeRestarts() shows browser,
##muffleWarning, and abort ...
options(opts)
warning(w$message)
## how can I get back from here to the calling point
## *without* muffling warnings ... ?
}
})
}
suppressWarnings2(sqrt(-1))
suppressWarnings2(sqrt(-1),abc)
It seems to me I'd like to have a restart option that just returns to
the point where the warning was caught, *without* muffling warnings ...
? But I don't quite understand how to set one up ...
Ben Bolker
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics andFax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] suppress *specific* warnings?
Not desperately important, but nice to have and possibly of use to
others, is the ability to suppress specific warnings rather than
suppressing warnings indiscriminately. I often know of a specific
warning that I want to ignore (because I know that's it's a false
positive/ignorable), but the current design of suppressWarnings() forces
me to ignore *any* warnings coming from the expression.
I started to write a new version that would check and, if supplied
with a regular expression, would only block matching warnings and
otherwise would produce the warnings as usual, but I don't quite know
enough about what I'm doing: see ??? in expression below.
Can anyone help, or suggest pointers to relevant
examples/documentation (I've looked at demo(error.catching), which isn't
helping me ... ?)
suppressWarnings2 - function(expr,regex=NULL) {
opts - options(warn = -1)
on.exit(options(opts))
withCallingHandlers(expr, warning = function(w) {
## browser()
if (is.null(regex) || grepl(w[[message]],regex)) {
invokeRestart(muffleWarning)
} else {
## ? what do I here to get the warning issued?
## browser()
## computeRestarts() shows browser,
##muffleWarning, and abort ...
options(opts)
warning(w$message)
## how can I get back from here to the calling point
## *without* muffling warnings ... ?
}
})
}
suppressWarnings2(sqrt(-1))
suppressWarnings2(sqrt(-1),abc)
It seems to me I'd like to have a restart option that just returns to
the point where the warning was caught, *without* muffling warnings ...
? But I don't quite understand how to set one up ...
Ben Bolker
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] suppress *specific* warnings?
On 10/21/2012 12:28 PM, Ben Bolker wrote:
Not desperately important, but nice to have and possibly of use to
others, is the ability to suppress specific warnings rather than
suppressing warnings indiscriminately. I often know of a specific
warning that I want to ignore (because I know that's it's a false
positive/ignorable), but the current design of suppressWarnings() forces
me to ignore *any* warnings coming from the expression.
I started to write a new version that would check and, if supplied
with a regular expression, would only block matching warnings and
otherwise would produce the warnings as usual, but I don't quite know
enough about what I'm doing: see ??? in expression below.
Can anyone help, or suggest pointers to relevant
examples/documentation (I've looked at demo(error.catching), which isn't
helping me ... ?)
suppressWarnings2 - function(expr,regex=NULL) {
opts - options(warn = -1)
on.exit(options(opts))
I'm not really sure what the options(warn=-1) is doing there, maybe its for
efficiency to avoid generating a warning message (as distinct from signalling a
warning). I think you're after something like
suppressWarnings2 -
function(expr, regex=character())
{
withCallingHandlers(expr, warning=function(w) {
if (length(regex) == 1 length(grep(regex, conditionMessage(w {
invokeRestart(muffleWarning)
}
})
}
If the restart isn't invoked, then the next handler is called and the warning
is handled as normal. So with
f - function() {
warning(oops)
2
}
there is
suppressWarnings2(f())
[1] 2
Warning message:
In f() : oops
suppressWarnings2(f(), oops)
[1] 2
For your own code I think a better strategy is to create a sub-class of warnings
that can be handled differently
mywarn -
function(..., call.=TRUE, immediate.=FALSE, domain=NULL)
{
msg - .makeMessage(..., domain=domain, appendLF=FALSE)
call - NULL
if (call.)
call - sys.call(1L)
class - c(silencable, simpleWarning, warning, condition)
cond - structure(list(message=msg, call=call), class=class)
warning(cond)
}
suppressWarnings3 -
function(expr)
{
withCallingHandlers(expr, silencable=function(w) {
invokeRestart(muffleWarning)
})
}
then with
g - function() {
mywarn(oops)
3
}
suppressWarnings3(f())
[1] 2
Warning message:
In f() : oops
g()
[1] 3
Warning message:
In g() : oops
suppressWarnings3(g())
[1] 3
withCallingHandlers(expr, warning = function(w) {
## browser()
if (is.null(regex) || grepl(w[[message]],regex)) {
invokeRestart(muffleWarning)
} else {
## ? what do I here to get the warning issued?
## browser()
## computeRestarts() shows browser,
##muffleWarning, and abort ...
options(opts)
warning(w$message)
## how can I get back from here to the calling point
## *without* muffling warnings ... ?
}
})
}
suppressWarnings2(sqrt(-1))
suppressWarnings2(sqrt(-1),abc)
It seems to me I'd like to have a restart option that just returns to
the point where the warning was caught, *without* muffling warnings ...
? But I don't quite understand how to set one up ...
Ben Bolker
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M1 B861
Phone: (206) 667-2793
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] suppress *specific* warnings?
On 12-10-21 09:08 PM, Martin Morgan wrote:
On 10/21/2012 12:28 PM, Ben Bolker wrote:
Not desperately important, but nice to have and possibly of use to
others, is the ability to suppress specific warnings rather than
suppressing warnings indiscriminately. I often know of a specific
warning that I want to ignore (because I know that's it's a false
positive/ignorable), but the current design of suppressWarnings() forces
me to ignore *any* warnings coming from the expression.
I started to write a new version that would check and, if supplied
with a regular expression, would only block matching warnings and
otherwise would produce the warnings as usual, but I don't quite know
enough about what I'm doing: see ??? in expression below.
Can anyone help, or suggest pointers to relevant
examples/documentation (I've looked at demo(error.catching), which isn't
helping me ... ?)
suppressWarnings2 - function(expr,regex=NULL) {
opts - options(warn = -1)
on.exit(options(opts))
I'm not really sure what the options(warn=-1) is doing there, maybe its
for efficiency to avoid generating a warning message (as distinct from
signalling a warning).
As may have been obvious, I was copying suppressWarnings() verbatim --
so I guess you'd have to ask R-core for the reasoning there ...
I think you're after something like
suppressWarnings2 -
function(expr, regex=character())
{
withCallingHandlers(expr, warning=function(w) {
if (length(regex) == 1 length(grep(regex,
conditionMessage(w {
invokeRestart(muffleWarning)
}
})
}
If the restart isn't invoked, then the next handler is called and the
warning is handled as normal. So with
f - function() {
warning(oops)
2
}
there is
suppressWarnings2(f())
[1] 2
Warning message:
In f() : oops
suppressWarnings2(f(), oops)
[1] 2
Great, thank you!
For your own code I think a better strategy is to create a sub-class of
warnings that can be handled differently
mywarn -
function(..., call.=TRUE, immediate.=FALSE, domain=NULL)
{
msg - .makeMessage(..., domain=domain, appendLF=FALSE)
call - NULL
if (call.)
call - sys.call(1L)
class - c(silencable, simpleWarning, warning, condition)
cond - structure(list(message=msg, call=call), class=class)
warning(cond)
}
suppressWarnings3 -
function(expr)
{
withCallingHandlers(expr, silencable=function(w) {
invokeRestart(muffleWarning)
})
}
then with
g - function() {
mywarn(oops)
3
}
suppressWarnings3(f())
[1] 2
Warning message:
In f() : oops
g()
[1] 3
Warning message:
In g() : oops
suppressWarnings3(g())
[1] 3
withCallingHandlers(expr, warning = function(w) {
## browser()
if (is.null(regex) || grepl(w[[message]],regex)) {
invokeRestart(muffleWarning)
} else {
## ? what do I here to get the warning issued?
## browser()
## computeRestarts() shows browser,
##muffleWarning, and abort ...
options(opts)
warning(w$message)
## how can I get back from here to the calling point
## *without* muffling warnings ... ?
}
})
}
suppressWarnings2(sqrt(-1))
suppressWarnings2(sqrt(-1),abc)
It seems to me I'd like to have a restart option that just returns to
the point where the warning was caught, *without* muffling warnings ...
? But I don't quite understand how to set one up ...
Ben Bolker
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
