quarto documents with rlang errors throw badly

[pawelru]

file _quarto.yaml:

project:
  type: website
  title: "test"

file test.qmd:

---
title: Test
---

Hello world!

```{r}
rlang::abort("oh no!")
```

Output:

❯ quarto render

processing file: test.qmd
1/3                  
2/3 [unnamed-chunk-1]
Error in `!continue`:
! invalid argument type
Backtrace:
  1. global .main()
  2. execute(...)
  3. rmarkdown::render(...)
  4. knitr::knit(knit_input, knit_output, envir = envir, quiet = quiet)
  5. knitr:::process_file(text, output)
     ...
  9. knitr:::call_block(x)
 10. knitr:::block_exec(params)
 11. knitr:::eng_r(options)
 14. knitr (local) evaluate(...)
 15. evaluate::evaluate(...)

Quitting from lines 8-9 [unnamed-chunk-1] (test.qmd)
Execution halted

The expected result is as when converted to stop():

❯ quarto render

processing file: test.qmd
1/3                  
2/3 [unnamed-chunk-1]
Error:
! oh no!
Backtrace:
  1. global .main()
  2. execute(...)
  3. rmarkdown::render(...)
  4. knitr::knit(knit_input, knit_output, envir = envir, quiet = quiet)
  5. knitr:::process_file(text, output)
     ...
 16. base::withRestarts(...)
 17. base (local) withRestartList(expr, restarts)
 18. base (local) withOneRestart(withRestartList(expr, restarts[-nr]), restarts[[nr]])
 19. base (local) docall(restart$handler, restartArgs)
 21. evaluate (local) fun(base::quote(`<smplErrr>`))

Quitting from lines 8-9 [unnamed-chunk-1] (test.qmd)
Execution halted

[hadley]

Duplicate of yihui/knitr#2366

[eternal-flame-AD]

I am the author of that issue, it looks like there is a bug here in introduced by #b834959 here:

b834959#diff-518dd3a35abbeadcd80541ab2ee49daa55dbd86f84cac0a083168e022073868cR155

If we go to the eval_error code path, there is no handler for it to return from and it will return NULL, which later in the if (!continue) will become a stop.

Calling handlers are established by withCallingHandlers. If a condition is signaled and the applicable handler is a calling handler, then the handler is called by signalCondition in the context where the condition was signaled but with the available handlers restricted to those below the handler called in the handler stack. If the handler returns, then the next handler is tried; once the last handler has been tried, signalCondition returns NULL.

CC: @yihui

[hadley]

Ok, fairly confident that this is better as of 33c1286

[pawelru]

Thank you!