Chapter8 Debugging in R

Up to this point, you have learned how to write R code to manipulate data, perform calculations, use loops, and apply functions efficiently. Inevitably, as your code becomes longer and more complex, things will go wrong. This is normal.

Debugging is not a sign of failure or lack of ability — it is a core skill of every programmer, data scientist, and actuary. In practice, a significant proportion of your time will be spent finding, understanding, and fixing errors, rather than writing new code from scratch.

This chapter focuses on:

  • understanding different types of errors in R
  • developing a systematic approach to debugging
  • learning common tools and habits that make debugging easier

The aim is not to eliminate errors (that is impossible), but to help you locate and fix them efficiently and confidently.

8.1 Types of errors in R

When something goes wrong, R usually tells you something — but not always in a way that is immediately clear. Broadly, errors fall into three categories.

  1. Syntax errors

Syntax errors occur when R cannot understand what you have typed. These are usually caused by:

  • missing brackets (), {}, []
  • missing commas
  • unmatched quotation marks
  • incorrect function structure
mean(1, 2, 3)

R will complain because mean() expects a single vector, not multiple arguments.

  1. Run-time errors

Run-time errors occur when the code is syntactically correct, but R cannot execute it:

x <- c(1, 2, 3)
x[10]

This returns NA, which may silently cause problems later in your code.

  1. Logical errors (the most dangerous kind)

Logical errors occur when:

  • the code runs
  • no error messages appear
  • but the result is wrong
mean(1:10 / 10)

The code is valid, but the calculation may not reflect what you were intending.

8.2 Systematic debugging workflow

When your code does not behave as expected, avoid randomly changing things and hoping it works. Instead, follow a structured approach.

  1. Read the error message carefully - Error messages often contain:
  • the type of error
  • the function involved
  • sometimes the line number

Do not ignore warnings — they frequently indicate deeper problems.

  1. Check object existence and names
ls()
class(x)
str(x)

Many bugs are caused by misspelled or overwritten object names.

  1. Check object types and dimensions
class(x)
length(x)
dim(x)
str(x)

Many functions behave differently depending on object type.

  1. Simplify the problem

Run your code line by line and inspect intermediate objects. Debugging becomes much easier when problems are isolated.

  1. Use print statements deliberately
print(x)

Printing intermediate values inside loops or functions is one of the most effective debugging techniques.

  1. Check edge cases and missing values

Always consider:

  • NA values
  • empty vectors
  • divisions by zero
  • first and last loop iterations

8.3 Useful debugging tools

  • traceback()
traceback()

Shows the sequence of function calls that led to an error.

  • browser()
browser()

Pauses execution so you can inspect objects interactively.

8.4 Good debugging habits

  • Assume the issue is in your understanding, not R
  • Test code on small examples
  • Validate results using intuition
  • Never trust output you do not understand

Most serious errors come from silent logical mistakes, not crashes.

8.5 Exercises

Exercise 8.1 

x <- c(1, 2, 3, 4, 5
mean(x)

Identify and fix the error.

Exercise 8.2 

x <- "10"
y <- 5
x + y

Explain the error and correct the code.

Exercise 8.3 

x <- c(2, 4, 6)
y <- x[5]

Why is this dangerous in larger scripts?

Exercise 8.4 

mean(1:100^2)

Explain what R computes and fix the code.

Exercise 8.5 

total <- 0
for(i in 1:10){
  total <- i
}
total

Explain the issue and correct the loop.