The second type of error your code might have is a run-time error, so-called because the error does not appear until you run the program. In C++, these errors generally occur because of an exception - an attempt to do an operation that is not allowed.
Run-time errors are rare in the simple programs you will see in the first few chapters, so it might be a while before you encounter one. When a run-time error occurs, the program “crashes” (terminates) and displays an error message that explains what happened.
When an exception occurs, the program may not tell you exactly where the issue was. To find it, we need to use a debugger (like the Codelens feature in Activecodes) that lets us run the code line by line or we need to add print statements and see where the output stops.
Sometimes while debugging it helps to add extra print statements to help diagnose exactly where an error occurs. Even something as simple as “Got to point A”, “Got to point B”, etc... can help you narrow down where a run-time error is occurring.
If there is a semantic error in your program, it will compile and run successfully, in the sense that the computer will not generate any error messages, but it will not do the right thing. It will do something else. Specifically, it will do what you told it to do.
Because logic errors happen when the code you wrote does not mean what you think it does, identifying semantic errors can be tricky. Sometimes they come from a simple typo. Other times they are a result of you not understanding exactly how some piece of code works.
The C++ compiler can sometimes detect that what you are doing might not make sense. When there is something that looks suspicious, the compiler may emit a warning. Warnings have the same format as syntax errors, only they don’t necessarily prevent the program from building.
The C++ compiler can be told to handle warnings in different ways. It can ignore them, it can issue warnings about them and continue building, or it can treat them as errors that prevent the code from being built. In this book you will get warnings. It is wise to treat any warnings as if they were errors.
But you can easily have a logic error that does not produce a warning. When everything in your code looks like it makes sense, but just isn’t what you wanted, there is no way for the compiler to help you. Again, using a debugger to run the code line by line and check the results can be a good way to find the issue.
Simple lines of code are easier to debug than complex ones. If you have a logic error, try to isolate it by breaking the code into smaller pieces and testing each one.
It is also often easier for people to understand a larger number of simple lines of code than a few very complex ones. And the compiler will quite likely produce the same object code either way. So favor writing code that is easy to read and debug.
