Using source("ASD.R") in R Markdown - stops when error in R Code

[ChristopherCosler]

Good morning Stats-Enthusiasts,

I have the following problem when knitting the R Markdown file: the process stops when an error message occurs while executing an R file called by source(). Let me give an example. At the beginning of the Markdown file, I use

setwd("C:/ASD/ASD/ASD")
source("XYZ.R")

This works perfectly. My problem is that it stops knitting when an error message occurs while executing the R code. This is annoying because I do not want to change the R code to get rid of the error (I know why there is an error and after some minor changes the command will make sense again, but I cannot make the changes right now).

I tried (try(souce("ASD.R")) which in a way helps because it does not stop knitting anymore, but it stops executing the R file at the moment the error occurs which is a pity because the really interesting statistics are computed at the end of the code.

Any ideas or solutions are highly appreciated :-)

[christophergandrud]

Hi @ChristopherCosler I'ld have to look at your code to give a detailed answer. But in general, errors (unlike warnings) force R to stop. So this doesn't really have anything to do with R Markdown.

That being said, why not place try around the code that causes the error in the ASD.R file or just comment it out with # until you are able to fix the problem causing the error?

[ChristopherCosler]

Thank you for the quick reply. It is indeed an error message, which does not force R to stop, only R Markdown. The error occurs because the command tries to summarize a variable that does not exist.

Both try and # solves the problem but I was hoping for a more long term solution, because currently up to five people are working on that code, so errors can easily happen. An error that occurs in one part of the analysis does not necessarily affect the other parts, so I was hoping I could just ignore them until my co-worker fixed the problems.

I am afraid that, in sharp contrast to the ideals of this course, the people we are writing the code for are not ready to disclose it yet. Sorry for that.

[christophergandrud]

No worries. Generally, if you are working with code that you expect to have errors in it, work on a separate branch until the errors are resolved, then merge back into master. This should help you avoid these sorts of problems.

You should aim for the master branch, especially in the remote GitHub repos, to run without errors to avoid this sort of problem. Don't commit to master if there errors in the code.