Computational Problem Solving with Java and Interactive Object Graphics

Syntax errors occur when initially writing a program. In Java, you might forget a closing curly brace or a semicolon at the end of a statement. Maybe you separate the elements of an array initializer with semicolons instead of commas, or your method reference is defined with a single colon instead of the :: operator. There are many opportunities to writie syntactially invalid Java.

The Java compiler is the authoritative source on syntax errors. By now you’ve no doubt seen plenty of errors after a compilation. The compiler output can be cryptic upon first glance. It is worth you time to read the output carefully. It can tell you everything you need to know. At a minimum, find the file and line number in the output. This gives you a place to start.

Fortunately, modern editors will help you find your syntax errors long before you compile your program. Good editors for programming may even suggest what might be wrong and offer a solution that can be performed automatically, such as adding a forgotten import. Language-specific editor plug-ins are especially useful. AI-driven plug-ins are now available as well. These will suggest the next thing that you may want to add to your program based on what you typed in the past. Be very careful with AI plug-ins. Make sure you understand what is suggested; there is no guarantee suggestions are correct.

When debugging a program, always fix the first reported syntax error first, and try to recompile. Frequently, the first error triggers a long list of what looks like additional errors. Fixing the first error often fixes them all, or a large number.

At the other end of the process are logic errors. These occur when your program apparently works perfectly. It compiles and runs just fine. Unfortunately, its behavior or output is wrong. Logic errors occur when you stop a loop too soon, reuse variables and forget to initialize them, define the conditions of a branch incorrectly, invoke the wrong method signature overload, etc.

Logic errors are caught during testing. You might be performing informal testing after implementing a feature, or you might have handed off your program to a formal testing team, who’s job it is to compare your program’s behavior against prewritten specifications. In any case, logic errors can be hard to find. It is difficult to anticipate how a program will be used once it is in the hands of someone else. Try to test all possible inputs and interactions, however improbable.

The last broad category of errors occurs after a program compiles, but something goes wrong while it is running. Java responds to such problems by throwing an exception. Like nearly everything else in Java, a thrown exception is an object created by instantiating a suitable Exception class. A thrown exception object may come from code in the Core Library, or you may instantiate and throw exceptions on your own. The particular Exception class instantiated and thrown should identify the detected problem.

If there is no intervention on the part of your program, Java will eventually print a trace of the current state of the call stack when the exception object is thrown. The call stack tells us everything that was underway at the time the error was detected. Use the call stack to find the exact file and line that threw the exception. Move down the call stack to see from where in your program the method was invoked. Depending upon the structure of your program, the call stack can be many levels deep. You should be able to trace the error all the way back to the initial trigger. The mistake could be at any level of the call stack. We’ll take a closer look at what the call stack does and how it functions in Section 12.2.

The important thing to know about runtime errors is that they may be caught at runtime, and handled gracefully, without causing your program to dump a trace of the call stack. Typical runtime errors include inadvertently dividing by zero, or attempting to open a file that does not exist. A trace of the call stack might be useful to you, but it is generally useless to the average user of your program. The message "File not found. Please try again." is far more useful to the average user than a trace of the call stack.

In this chapter we will explore exceptions, what causes them to be thrown, how to catch and handle them, and even how to define our own exception classes, instantiate exception objects, and throw them.