假设您有一个不会干净利落的R降价文档。
我知道您可以将knitr
块选项error
设置为TRUE
,以请求继续进行评估,即使存在错误也是如此。您可以通过error = TRUE
或通过knitr::opts_chunk$set(error = TRUE)
以更全球化的方式为单个块执行此操作。
但有时会出现针对编织过程仍然致命的错误。我最近遇到的两个例子:当RStudio不可用时,尝试unlink()
当前工作目录(oops!)并从内联R代码调用rstudioapi::getVersion()
。是否对这些类型的错误进行了一般性描述,即error = TRUE
范围之外的错误?有没有办法容忍内联R代码与块中的错误?
另外,在这种情况下,是否有更多官方方法可以提前停止编织或自动调试?
答案 0 :(得分:30)
要从编织过程中提前退出,您可以在源文档中的任何位置使用函数knitr::knit_exit()
(在代码块或内联表达式中)。调用knit_exit()
后, knitr 将忽略文档的所有其余内容并写出目前为止收集的结果。
目前无法容忍内联R代码中的错误。您需要确保内联R代码始终运行且没有错误 1 。如果确实发生错误,您应该在控制台中看到Quitting from lines x1-x2 (filename.Rmd)
形式的 knitr 日志产生错误的行范围。然后,您可以转到filename.Rmd
文件,看看从x1
到x2
的行有什么问题。同样的事情适用于具有块选项error = FALSE
的代码块。
除了上面提到的错误类型之外,找到问题的根源可能很棘手。例如,当您无意中unlink()
当前目录时,它不应该停止编织过程,因为unlink()
无论如何都成功了。编织过程后可能会遇到问题,例如,LaTeX / HTML无法找到输出图形文件。在这种情况下,您可以尝试将knit_exit()
逐个应用于文档中的所有代码块。实现此目的的一种方法是设置块挂钩以在某个块之后运行knit_exit()
。下面是使用线性搜索的示例(您可以通过使用二分法来改进它):
#' Render an input document chunk by chunk until an error occurs
#'
#' @param input the input filename (an Rmd file in this example)
#' @param compile a function to compile the input file, e.g. knitr::knit, or
#' rmarkdown::render
knit_debug = function(input, compile = knitr::knit) {
library(knitr)
lines = readLines(input)
chunk = grep(all_patterns$md$chunk.begin, lines) # line number of chunk headers
knit_hooks$set(debug = function(before) {
if (!before) {
chunk_current <<- chunk_current + 1
if (chunk_current >= chunk_num) knit_exit()
}
})
opts_chunk$set(debug = TRUE)
# try to exit after the i-th chunk and see which chunk introduced the error
for (chunk_num in seq_along(chunk)) {
chunk_current = 0 # a chunk counter, incremented after each chunk
res = try(compile(input))
if (inherits(res, 'try-error')) {
message('The first error came from line ', chunk[chunk_num])
break
}
}
}
error = TRUE
用于代码块是个好主意,因为有时我们想要显示错误,例如,出于教学目的。但是,如果我也允许内联代码出错,作者可能无法识别内联代码中的致命错误。内联代码通常用于嵌入值内联,并且我认为如果内联值是错误则更有意义。想象一下像The P-value of my test is ERROR
这样的报告中的句子,如果 knitr 没有发出错误信号,则需要作者非常仔细地阅读报告输出以发现此问题。我认为不得不依靠人眼来发现这样的错误。答案 1 :(得分:9)
恕我直言,调试Rmd文件有困难,警告说出错了。我有一个经验法则:重做外面 Rmd。在Rmd内进行渲染,仅渲染。这使得Rmd代码变得简单。
我的大型R程序看起来像这样。
$js_array = array();
$js_array = json_encode($arrayOfPhotos);
echo" <script> var arrayOfPhotos = '.$js_array.'; </script>" ;
echo '<script>alert(arrayOfPhotos[0].filename);</script>';
(此处, doAnalytics 返回列表或环境。该列表或环境通过 envir 参数传递给Rmd文档,使得分析计算的结果可用在文件里面。)
doAnalytics 函数执行复杂的计算。我可以使用常规工具调试它,我可以轻松检查其输出。当我打电话给 rmarkdown :: render 时,我知道硬件工作正常。 Rmd代码只是&#34;打印这个&#34;和&#34;格式化&#34;,易于调试。
这种责任分工对我很有帮助,我可以推荐它。特别是与调试隐藏在动态渲染文档中的复杂计算的令人费解的任务相比。