CRAN请求用\donttest{}替换\dontrun{}后R包中的问题

我向CRAN提交了一个包，他们要求我在Rd文件中将

\dontrun{}

替换为

\donttest{}

，然后重新提交。我用

\dontrun{}

包装了一些应该抛出错误消息的示例

在将

\dontrun{}

替换为

\donttest{}

后，我进行了一些测试，

R CMD check

仍然成功，但碰巧现在

devtools:：check（）

和

R CMD check--as-cran

由于

\donttest{/code>中包含的示例而失败：

使用--run donttest。。。错误

浏览了一番之后，我了解到R4.0.0已经更改了
R CMD check--as cran
以运行
\donttest
示例。根据R-devel的研究：

“R CMD check--因为cran现在运行\donttest examples（由example（）运行），而不是指示测试人员这样做。在开发过程中，可以通过将环境变量R_check_donttest_examples设置为假值暂时避免此问题。”

由于我打算将包重新提交给CRAN，因此在本地将
\R\u CHECK\u DONTTEST\u EXAMPLES\u
设置为
false
对我没有帮助

我还发现最近在一个
devtools
问题上进行了讨论，Hadley Wickham指出：

一般来说，现在如果您不想在CRAN\dontrun{}上运行测试，则更可能工作，但使用\dontrun{}可能会导致初始提交失败

所以现在我不知道如何继续，因为如果我用所需的更改重新提交包，我已经知道它将在
R CMD check中抛出一个错误——正如cran
，因此它可能会失败cran的自动预测试

编辑：

按照建议，我尝试了
if（interactive（））{}
而不是
\dontrun{}
。这个解决方案在
R CMD check中成功了——正如cran
和
devtools:：check（）
一样，但我认为这不是解决这个问题的最合适的方法，因为它不能很好地处理
example（）
（抛出一个错误，并且不显示剩余的示例）
\dontrun{}
使用
example（）
效果更好，因为它打印了所有示例，但注释了用
\dontrun{}
包装的示例，我认为包示例不是“应该抛出错误消息的示例”的正确位置

当您将这些“示例”转移到单元测试时，您的问题将很容易解决

有

expect_error()
expect_warning()

查看您的包是否按预期抛出警告/错误

如果你真的想告诉用户应该避免输入什么，也许你可以把它作为注释添加到示例或其他文档中（详细信息，参数）

您经常在其他包示例中看到以下内容：

## Example for working
function(x, abc = "5)

## This would give an error because
# function(x, abc = "falsch")

## Working example 2
function(x)
x <- x+y

##工作示例
函数（x，abc=“5）
##这将给出一个错误，因为
#函数（x，abc=“falsch”）
##工作实例2
功能（x）
x如果您知道某个东西会抛出错误，可以将其包装在
try（）
中

##失败代码示例
尝试（停止（“出现错误”））
我投票结束这个问题，因为它更适合
r-package-devel@r-org
邮件列表…这是一个管理问题，而不是编程问题…”我用\dontrun{}来包装一些应该抛出错误消息的示例。“-也许只是将这些从示例中删除，然后将它们放在单元测试的测试中？或者这些示例会引发用户理解软件包所需的错误？@SteffenMoritz删除这些示例确实会修复R CMD check中的错误。但是在这个软件包中，我有一些函数，根据特定的条件，通过提供信息的错误消息来停止执行，我认为说明这一点是有用的（甚至认为不是必要的）。我发布了一个答案：）我经常看到的是，人们在示例中添加了一些内容，但对其进行了注释。可能是一个很好的折衷办法。@SteffenMoritz您是对的，如果（interactive（））
在我试图不运行的示例行中，文档将具有
，从这个意义上讲，
\donttest{}
将导致文档“更整洁”，因为
\donttest{}
未打印。但是我不认为
\donttest{}
在这里是一个选项，因为它在运行
R CMD check时会返回实际的错误——就像cran
（以及在运行
example（）时一样）
。但与
\dontrun
相比，这仍然是一个改进，因为
\dontrun
也会打印到文档中。感谢您的回答！我已经在使用单元测试来确保错误消息如预期的那样（以及其他内容）。我提到的错误消息并不是告诉用户应该避免什么类型的输入。想象一下在
foo（x，y）
中使用
helper\u foo（x，y）
停止执行
foo（）
如果有关
x
和
y
的某些条件为
TRUE
，并通知用户哪些条件触发了错误。
helper\u foo（x，y）
是一个函数，而不仅仅是嵌入
foo（）中的代码
因为它可以在许多其他具有类似输入结构的函数中使用。感谢您的回答。这似乎是迄今为止最好的解决方案。它成功地执行了
R CMD check--as cran
，并在
示例（）中正确显示错误消息
不停止执行。我仍在考虑我的选择，但如果这最终成为实际的解决方案，我会回来接受这个答案。我现在可以确认CRAN接受了这个解决方案。