Valid use cases for error=TRUE, include=FALSE

[rundel]

---

By filing an issue to this repo, I promise that

• I have fully read the issue guide at https://yihui.org/issue/.
• I have provided the necessary information about my issue.
  • If I'm asking a question, I have already asked it on Stack Overflow or RStudio Community, waited for at least 24 hours, and included a link to my question there.
  • If I'm filing a bug report, I have included a minimal, self-contained, and reproducible example, and have also included xfun::session_info('knitr'). I have upgraded all my packages to their latest versions (e.g., R, RStudio, and R packages), and also tried the development version: remotes::install_github('yihui/knitr').
  • If I have posted the same issue elsewhere, I have also mentioned it in this issue.
• I have learned the Github Markdown syntax, and formatted my issue correctly.

I understand that my issue may be closed if I don't fulfill my promises.

---

The current implementation of knitr enforces a stop on first error evaluation when include=FALSE regardless of the error option's value.

knitr/R/block.R

Lines 188 to 194 in 0a77ac2

	evaluate(
	code, envir = env, new_device = FALSE,
	keep_warning = !isFALSE(options$warning),
	keep_message = !isFALSE(options$message),
	stop_on_error = if (options$error && options$include) 0L else 2L,
	output_handler = knit_handlers(options$render, options)
	)

I understand why this was chosen and why this makes sense as default behavior for most use cases, however I think there needs to be some way to override this in certain circumstances.

Specifically, I currently have a use case where I am taking student submitted Rmd documents and I am attempting to output and highlight a small section of the overall document. Since there is not an effective way of determining dependence between chunks, my brute force approach involves setting all preceding chunks to include=FALSE and knitting. This works as expected if none of the chunks have errors, however if any of the previous chunks do have an error, even if this has no bearing on the chunk of interest's ability to run, the knit fails. As such, I would like to be able to use error=TRUE in this circumstance and allow everything to run regardless of any errors along the way but this is not currently possible.

I've experimented extensively with trying to achieve the same effect with error hooks and options but this ends up being both clunky and not 100% effective (lingering markdown code blocks). My current solution involves just wrapping the code in each chunk with try() but this is also not idea as it has slightly different behavior from error=TRUE with the chunk stoping execution after the first error.

I don't know what a prefered solution would look like for you, but it seems like something as simple as adding a new option that modifies this behavior could make this possible. Maybe something like error.allow.

[atusy]

Maybe you can workaround with

knitr::ops_chunk$set(error = TRUE, echo = FALSE, results = 'hide', fig.show = 'hide')

[rundel]

This is not sufficient as the error message will still be printed in the document.

[atusy]

You are right. Then, this:

knitr::opts_chunk$set(error = TRUE,
                      echo = FALSE,
                      results = 'hide',
                      fig.show = 'hide',
                      message = FALSE,
                      warning = FALSE)
knitr::knit_hooks$set(
  error = function(...) NULL
)

[atusy]

Oh, if you include nothing and accept error, you do not even have to evaluate.

knitr::opts_chunk$set(eval = FALSE, echo = FALSE)

[yihui]

@atusy's first solution could solve the problem when you need to evaluate the previous code chunks; the section solution works when you don't need to evaluate them.

That said, I just added support for error = 0, which means knitr will never stop regardless of include = FALSE. This should be cleaner than setting a bunch of other chunk options. Thanks!

[github-actions]

This old thread has been automatically locked. If you think you have found something related to this, please open a new issue by following the issue guide (https://yihui.org/issue/), and link to this old issue if necessary.