This error is mostly caught by the compiler.
The other error is a semantic bug. This is usually an error in the logic you used to write a program. For example, to compute the area of a rectangle, you might have an incorrect formula such as height + width, instead of height * width.
Since both are valid Java expressions, the compiler can't help you. The compiler has no idea what your program is trying to do.
This kind of bug is much harder to find. The compiler can't help out.
When you are testing your program, you feed input to your program, and then see if the result is what you expect. Sometimes you can even write a program that does this automatically for you.
Once you see an output that is not what you expect, you have to figure out where it happened. This can be time-consuming. It often requires that you trace the code. Tracing the code means to follow your code one line at a time, keeping track of variable's values at each step. You are behaving just like the computer, although you're much, much slower.
You do this with the intention of understanding what's wrong. Only when you know what is wrong can you fix the problem.
This requires a good deal of patience, and many beginners find they lack patience. They'd rather change the code, and hope it works, because the time it takes them to find an error seems way too long. Needless to say, this technique of changing the code and hoping it fixes things rarely works.
I joke that it's like fixing a car, by taking an axe and chopping a few things in the engine, hoping that it all works.
I once talked to a student, who, after 20 minutes, could not find what was wrong with his program. I had to suppress a smile. I had known people who've spent days trying to figure out their error. I'm not saying days are typical, but 20 minutes can be a very short time when it comes to debugging.
In fact, much of programming is spent debugging. When you start out, you may spend half your time debugging, possibly more. Of course, with experience, you'll learn how to avoid many bugs. You'll learn to check for certain things, and learn to test your code well, so you can find errors quickly. The better you know the ins and outs of how Java works, the less time you need to spend debugging. It also helps if you have a sharp, inquisitive, and patient personality.
People say you can't teach debugging. You can, but it's not easy. It relies on you, the programmer, to learn the lessons of debugging, and to use your brain to figure things out.
However, it can be slow. Adding print statements to your program forces you to recompile, then look at the results. Once you find the bug, you have to go back and remove the print statements that you were using to debug.
You can also use a program called a debugger. A debugger is a bad name for the program. It doesn't debug the code at all. You debug it. Instead, it helps you to trace out the code. It goes step by step, and can stop at various points called breakpoints, which you indicated. At those breakpoints, you look at values of variables and also something called the stack.
The debugger for Java isn't particularly good. Nevertheless, one advantage of a debugger is that you don't have to recompile the code. The big disadvantage of debuggers is that it's one additional program you have to master. Not all debuggers are designed the same way, which means using a different debugger may require learning the features of the new debugger. Most debuggers work about the same. Even so, you may have to get a manual just to get the most out of the debugger.
Still, most Java programmers use debuggers frequently to help them find errors. We'll talk about them later on.