Errors and Debugging

Created By: Geoffrey Challen
/ Updated: 2022-09-07

This lesson focuses on one critical goal: staying sane in CS. Programming and computer science can be incredibly frustrating! Machines are highly-responsive but also highly-inhuman, and too much influence from them can be harmful.

We'll address both left and right brain sanity. To satisfy your logical and critical left hemisphere, we'll look into several of the common error messages that you'll experience in CS 124 and discuss how to fix them. And to nuture your creative and intuitive right hemisphere, we'll talk about how you stay human while learning to communicate with machines.

Debugging Challenge

But let's start with some debugging practice!

Handling Error Messages

All programmers make mistakes. All of the time. But you learn two things with time. First, how to fix your mistakes quickly. And second, that you are never going to stop making mistakes, so you might as well get used to it!

Below we'll walk through the three common kinds of error messages you'll need to handle in CS 124:

  1. ktlint error messages, caused by incorrect code formatting
  2. compiler errors that occur when your code has syntax errors
  3. testing failures that result when your program doesn't do the right thing

Based on our prior experience, you should expect to make a lot of these mistakes. In Spring 2020, around 500 CS 124 students together made:

  • 153,930 compiler errors, and
  • 136,260 testing errors

So get ready to make your own contribution to that total this semester. But there are some stategies that you can use to handle errors. Let's go through each category one by one.

Compiler Errors

Before Kotlin executes your program it transforms it through a step called compilation. We'll discuss this in more detail in a later lesson. But certain types of errors can occur during this step.

You can divide them broadly into two categories:

  • Kotlin has no idea what you are trying to do
  • Kotlin understands what you want to do but has noticed a potential problem

Let's look at both of these scenarios and how to address the errors that result.

Discuss compiler errors, what they mean, and how to fix them.

Runtime Errors

Just because the compiler doesn't find any problems doesn't mean that your code is correct! It can still cause an error when it is executed. Below we examine runtime errors and how to fix them:

Discuss runtime errors using ArrayIndexOutOfBounds as an example.

Testing Errors

A lot of the code that you write in this class will be tested to determine if it is correct. This is done by running your code—like a function, for example—with lots of different inputs. If we find a case where your code doesn't match up with the solution, we'll show you that failing input.

In the walkthrough that follows we'll try and explain a bit about how the testing process works and how to evaluate the output.

Show how to complete the homework problem above. Feel free to cover multiple approaches!

assert, require, check

Hopefully by now you'll have noticed that writing correct code is hard. There are a lot of ways to make mistakes. So programmers are always on the lookout for ways to make their lives easier and attempt to avoid bugs before they happen.

One way to do this is to use another feature of Kotlin known as runtime checks. Let's look at how they work:

Discuss assert, require, and check.

One important caveat: assert statements are not always turned on when you code is run. Typically they are enabled during development (when the programmers are running the code) and disabled in production (when actual users are running the code). Don't worry: assert is enabled on all of our playgrounds and for all of our homework problems. And require and check always work, so they can be safely used both in development and during production. We'll have you start using these checker methods on homework problems soon!

Now let's look at a simple example where we might want to use assert, require, or check.

Use a motivating example to describe where you might want to use assert, check, or require. Probably focus on require.

Show how to complete the homework problem above. Feel free to cover multiple approaches!

Staying Sane

Hopefully the walkthroughs and the statistics we presented above help convince you of one thing: you're going to make mistakes. We have both good news and bad news about that:

  • All programmers make mistakes: meaning that, just because you make mistakes, doesn't mean you aren't good at this
  • All programmers make mistakes: and keep on making mistakes, so you'd better start getting used to it!

All day we'll be discussing frustration, failure, and sanity. Below we talk a bit about how we work through those feelings in our own lives, and how we try and maintain a positive relationship with technology.

Discuss sanity in CS.

Show how to complete the homework problem above. Feel free to cover multiple approaches!

More Practice

Need more practice? Head over to the practice page.