15 How to make the most of R’s cryptic error messages
Written by Shirley Deng and last updated on 7 October 2021.
15.1 Decrypting the cryptic
More often than not, R will spit out errors that give us very little information on what they actually are.
We have two options here:
- Try to get rid of the error
- Try to fix the error
While getting rid of error messages can bring us momentary relief, we’re likely to encounter more issues along the way using hastily developed “solutions.”
15.1.1 Shootin’ the troubles
15.1.1.2 Example 1
While TAing an introductory data science course, one of the most common errors students encountered while working with R Markdown looked like this:
! Package inputenc Error: Unicode character μ (U+03BC)
(inputenc) not set up for use with LaTeX.
Try other LaTeX engines instead (e.g., xelatex) if you are using pdflatex. See https://bookdown.org/yihui/rmarkdown-cookbook/latex-unicode.html
Error: LaTeX failed to compile ProblemSet.tex. See https://yihui.org/tinytex/r/#debugging for debugging tips. See ProblemSet.log for more info.
Execution haltedOne way to get around this error would be to follow the suggestion and use xelatex as our LaTeX engine. For a PDF document, this would mean using the following in the header chunk:
output:
pdf_document:
latex_engine: xelatexBut what if we need to use a different LaTeX engine? What if using xelatex doesn’t get rid of the Package inputenc Error? Are there other ways to deal with this error?
One student suggested that we make an exemption for the μ character by adding the following to the header chunk:
header-includes:
- \DeclareUnicodeCharacter{03BC}{μ}15.1.1.3 Example 2
Now, another common error was this here:
! Package inputenc Error: Unicode character ， (U+FF0C)
(inputenc) not set up for use with LaTeX.
Try other LaTeX engines instead (e.g., xelatex) if you are using pdflatex. See https://bookdown.org/yihui/rmarkdown-cookbook/latex-unicode.htmlThis is the the same type of error as the earlier example, but with a different character specified - the Chinese full-width comma.
If we simply made an exemption for the μ character as the student suggested, then we’d still encounter the same error for other characters, like the ，.
Recall that LaTeX is designed to use commands to generate symbols.
We notice that this error specifically tells us that there may be an issue with a given unicode character. In the Example 1, μ.
So we can try searching the document to see where μ may appear. If we find any μ’s, great! Then we just need to avoid using μ in order to get our document to knit.
Then one fix for this error would be to replace all occurrences of μ with \mu, the laTeX command for the character.
In this example we could try replacing all occurrences of ， with ,, a regular degular comma generated by an English language keyboard, to allow us to knit our document.
But is there a way for us to prevent errors like these from popping up again?
After all of our trials and tribulations, we find that LaTeX probably doesn’t like when we generate the symbols ourselves. After all, there are only a handful of symbols that don’t need an escape or any sort of special handling to ensure that they show up properly in our knitted document.
Moving forward, it may be a good idea to try to use LaTeX commands for special characters or symbols whenever possible.
Ultimately, this was the solution that allowed most students to knit their R Markdown documents!
It’s one thing to get our code to work, but another thing to make sure we don’t have to work our code.
For the rest of this section on R’s cryptic error messages, we’ll be going over some common errors and how we can get around them.
15.2 Knitting makes a great pastime
The best way to minimize dealing with R Markdown errors in the first place is to knit often.
If we knit periodically as we work, then if or when we encounter an error, we’ll know which bit of code it came from.
Often times, one “mistake” can cause multiple error messages. In the case of Example 1, the μ character not only caused R to spit out ! Package inputenc Error, but Error: LaTeX failed to compile as well.
It’s much easier to deal with errors one by one than to deal with them all at once in a tangled mess.
15.2.1 Parm for your copypasta?
This also applies when we need to copy and paste bits into our documents.
As we saw in Example 2, it’s not easy to spot the difference between ， and ,. This is especially the case when we have a whole wall of text written up (i.e., the entire R Markdown document) to look through.
When copying and pasting, it’s best to copy small sections at a time, knitting in between each. This will allow us to isolate any issues like the Package inputenc Error.
15.2.2 Code
When it comes to code, we can run code without knitting the entire file, be it R or R Markdown.
This is especially handy when our R code uses a lot of memory and takes a long time to compile or knit. Rather than having to run the entire document, including all the bits we already know work, we can just test run an isolated part.
Simply select the desired code, and use the appropriate keyboard shortcut to run:
-
Cmd+Returnon Mac -
Ctrl+Enteron Windows and Linux
Note: A list of RStudio keyboard shortcuts can be found here
15.2.3 Knitting’s not for me
A fair amount of students have encountered the following error:
Error in contrib.url(repos, type) :
trying to use CRAN without setting a mirrorIf we do a little search…
?contrib.urlWe get the impression that we had some issues installing a package.
Keep in mind that we install packages for our R sessions, but only need to load them when we knit our R Markdown documents.
In other words, don’t use install.packages() in any of your R Markdown document code chunks!
Instead, you can either:
- click on the “Install” button in the yellow bar near the RStudio toolbar,
- or run
install.packages()in the console instead.
15.3 Have you tried turning it off and on again?
This may sound like we’re trying to get rid of the error instead of fixing it, but rest assured, we’ll see how it can be quite insightful at times.
15.3.1 Time waits for no man
To make debugging easier, some instructors may choose to have their students use RStudio on JupyterHub or RStudio Cloud, instead of a local installation.
JupyterHub and RStudio Cloud will automtically use the latest versions of R and RStudio available, so we don’t have to manually update our local installations.
This is great for when we need to use packages that aren’t configured for our OS. Hem hem, I’m speaking to you, rstan and brms on macOS.
However, using RStudio on the cloud often brings about a new problem: Status code 403 returned.
This often happens due to long (or sometimes even short) periods of inactivity. The RStudio team has not found a best solution for it yet, but the old turn it off and back on trick seems to fix it.
Some people suggest logging out and logging back in, while others suggest refreshing the page.
Note: Keep in mind that you have to install packages again each time you start a new RStudio session on JupyterHub.
15.3.2 Getting back on track when we run
Remember that note up there about installing packages for every new RStudio session on JupyterHub? Yes, the one three lines above this.
A number of students posted on their course discussion board about getting a Could not find function "glimpse" error.
Why would R not be able to find glimpse()?
Recall that glimpse(), like the pipe %>% and like tibble(), aren’t base R. Rather, we can access them by installing and loading the dlpyr or tidyverse packages.
If we don’t load the package, we can’t use the function.
Sometimes we might forget whether a line’s been run or not, or that we restarted a new R session, and mistakenly forget to install or load a package before attempting to run our code.
15.3.2.1 Example 4
Suppose we mistakenly run the same line of code it twice.
Try running the following code and see what happens:
# Uncomment it first
# mtcars <- mtcars %>% select(-mpg)
# mtcars <- mtcars %>% select(-mpg)We get an error! Error: Must subset columns with a valid subscript vector.
Now, this error message doesn’t give us much information about what’s wrong with our code.
But, when we restart our R session it works fine again:
Let’s take a closer look at what the line mtcars <- mtcars %>% select(-mpg) is doing, and why running it twice causes us issues.
We see that the line .mtcars <- mtcars %>% select(-mpg) removes the variable mpg from mtcars. Hence, if we run it once, there is no mpg left to be removed the second time.
Sometimes we just have code that won’t work if we run it more than once, and this is a situation where the old turn it off and back on trick helps us solve our problems, rather than just get rid of them.
Similarly, sometimes we run code in the console but don’t have it written in any chunks of our R Markdown document - maybe it was accidentally removed. If you were able to run the code before knitting, these are plausible situations. As a result, we may run into errors when R tries to knit our document.
All in all, when in doubt, you can start fresh by quitting and restarting your R session.
Note: This can especially be an issue if we’ve used set.seed(). Forgetting to set a seed when creating simulations of random objects can drastically change our results!
Note: If there are any helper files left behind from a R Markdown document that couldn’t knit, like .aux, delete them before trying to knit again.
15.4 Clopening
Encounter something like ! Package amsmath Error: \hat allowed only in math mode.?
This can be a little cryptic if we only have \hat{\beta} in our R Markdown document, and it appears fine as \(\hat{\beta}\) before knitting. It shows up, so we must be in math mode. What’s the problem?
It’s likely that there are open brackets, braces, parantheses, etc. - i.e. an extra one was either added or removed.
| So whenever you use one of these… | make sure it comes with one of these |
|---|---|
\( |
\) |
\[ |
\] |
$$ |
$$ |
\begin{aligned} |
\end{aligned} |
{ |
} |
15.5 Warnings, not errors
Sometimes we see some scary red text after knitting or compiling, and we worry that we have some cumbersome errors to deal with. However, red text is not always indicative of errors.
R also colours their warnings in red, too.
15.5.1 Example 5
Run the following code, and see what R tells us in response.
mtcars %>%
group_by(gear) %>%
summarise(qs = quantile(disp, c(0.25, 0.75)), prob = c(0.25, 0.75))
#> `summarise()` has grouped output by 'gear'. You can override
#> using the `.groups` argument.
#> # A tibble: 6 × 3
#> # Groups: gear [3]
#> gear qs prob
#> <dbl> <dbl> <dbl>
#> 1 3 276. 0.25
#> 2 3 380 0.75
#> 3 4 78.9 0.25
#> 4 4 160 0.75
#> 5 5 120. 0.25
#> 6 5 301 0.75We see that we get the following:
`summarise()` has grouped output by 'gear'. You can override using the `.groups` argument.This is not an error, but a warning.
If we want to get rid of warnings for just one code chunk, we can put warning=FALSE or warning=F in the little knitr chunk options, like this:
```{r, warning=FALSE}
# your code here
```
Alternatively, if we want to “turn off” warnings for our entire document, we can put this at the beginning of our R Markdown document, right after the YAML header chunk:
```{r, include=FALSE}
knitr::opts_chunk$set(warning = FALSE)
```
15.5.1.0.1 Note: More information on chunk options can be found here
With that said, this specific warning can be resolved exactly as it suggests: using the .groups argument, as below.