قراءة تتبّعات المكدس (stack traces)

Written Explanation

Anatomy of a trace

Here is the output of a real crash (Example 1 below):

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index 5 out of bounds for length 5
	at Report.total(Report.java:5)
	at Main.main(Main.java:5)

Read it in layers.

1. The first line is the headline. Exception in thread "main" says the problem happened in the main thread (your programs so far have one). Then comes the exception type, java.lang.ArrayIndexOutOfBoundsException, and after the colon the message. The Java documentation says the first line of a printed trace is the throwable's name, a colon and space, and its message (or the name alone if there is no message).
2. The at lines are stack frames, one per method call that was active, each with the form at Class.method(File.java:line). The Java documentation says the top of this list is the most recent call, which is typically where the exception was created and thrown, and the last line is the bottom of the stack, the start of the sequence of calls (such as main).

Compare with the call-stack picture from BEG-014-L05: that drawing had the newest frame at the top, and the trace prints in the same order.

The three-move reading

1. Read the first line, slowly. What kind of problem (the type) and what exactly (the message)?
2. Find the first at line that is in your code. It is the place in your program closest to the failure. Click it: IntelliJ typically shows the File.java:line part as a link that opens that line (check your version).
3. Read downward to see who called you and with what. This tells you how execution arrived.

In the example, move 1 says "an array index of 5 was used on an array of length 5". Move 2 lands on Report.java:5. Move 3 shows that Main.main called it at Main.java:5.

Read the message literally

Messages are usually precise. Index 5 out of bounds for length 5 means: the program asked for element 5, but an array of length 5 has valid indexes 0 to 4 (as in BEG-015). That is nearly always an off-by-one, or a loop that goes one step too far. You do not need to guess: the message contains the failing index and the length.

A NullPointerException in current JDKs usually says what was null. The Java documentation describes that the message gives a description of the null reference when the information is available. In our run it read Cannot invoke "String.toLowerCase()" because "email" is null. That points at the variable. Note that this detail shows real names only if the code was compiled with debugging information (IntelliJ includes it by default, per its documentation). When it was not, the same message showed "<parameter1>" in our test, and you count parameters instead.

Frames from libraries

Sometimes the top lines are not yours:

Exception in thread "main" java.lang.NumberFormatException: For input string: "1O"
	at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:67)
	at java.base/java.lang.Integer.parseInt(Integer.java:662)
	at java.base/java.lang.Integer.parseInt(Integer.java:778)
	at Parse.quantity(Parse.java:3)
	at Parse.main(Parse.java:8)

The first three frames are Java's own code (java.base is the module that holds it). They tell you where the exception was created, but not where your mistake is. The rule is to skip down to the first line with your class, here Parse.quantity(Parse.java:3): your call to Integer.parseInt received a bad string. The exact library line numbers depend on the JDK version, so do not rely on them.

Long, repeating traces

A trace with the same line repeated hundreds of times is the signature of a runaway recursion (BEG-014-L06):

Exception in thread "main" java.lang.StackOverflowError
	at Deep.count(Deep.java:3)
	at Deep.count(Deep.java:3)
	at Deep.count(Deep.java:3)

Our run printed about a thousand such lines. You do not read them all. Look at the first few and the last one, and ask why the method keeps calling itself without stopping.

Caused by

Sometimes one failure is wrapped inside another, and the printout has sections beginning Caused by:. The Java documentation says each cause is printed as Caused by: followed by its own frames, and that ... n more means the remaining frames are identical to the enclosing trace's last frames and not repeated. Read the last Caused by: first, since that is the original problem. You will meet wrapped exceptions properly later; for now, recognize the shape.

From the trace to the cause

The line in the trace is where the program failed, which is not always where the bug is. If Customer.emailDomain crashes because email is null, the bug is probably in whoever passed null. The trace gives you the chain to follow: set a breakpoint at the failing line, then use the Frames tab to select each caller and read its variables.