Read the error before you change anything

Java errors come in two flavours. Compile errors appear before the program runs and come with a file name and line number. Runtime exceptions appear while the program is running and come with a stack trace.

One rule saves a lot of time: fix only the first compile error, then compile again. A single early mistake, like a misspelled variable, can trigger a whole list of errors further down that disappear on their own once the first one is gone.

1. cannot find symbol

error: cannot find symbol
  symbol:   variable totl

int total = 0;
for (int i = 0; i < 5; i++) {
    totl += i;
}

Java can't find anything called totl. Nine times out of ten it's a typo. The other usual causes are using string instead of String, writing system.out in lowercase, or declaring a variable inside a loop or if block and then using it after the block has closed. Variables only live inside the braces where they were created.

Fix: correct the spelling or move the declaration to a wider scope.

2. incompatible types: possible lossy conversion

error: incompatible types: possible lossy conversion from double to int

double price = 19.99;
int rounded = price;

Java refuses to squeeze a double into an int silently because the decimal part would be lost. You have to say you meant it.

int truncated = (int) price;               // 19
int rounded = (int) Math.round(price);     // 20

Note that the cast just chops the decimals off. If you wanted normal rounding, use Math.round.

3. missing return statement

static String grade(int mark) {
    if (mark >= 70) {
        return "Distinction";
    } else if (mark >= 40) {
        return "Pass";
    }
}

The compiler looks at every possible path through the method. If a mark of 30 gets in, no branch returns anything, so it stops you. It doesn't matter that you "know" the mark will always be valid.

Fix: end with a branch that covers everything left.

    } else {
        return "Fail";
    }

4. variable might not have been initialized

int total;
if (scores.length > 0) {
    total = scores[0];
}
System.out.println(total);

Same logic as the missing return. If the if condition is false, total never gets a value, and Java won't let you read a local variable that might be empty.

Fix: give it a starting value where you declare it, int total = 0;.

5. Comparing strings with ==

This one doesn't produce an error message at all, which is why it's so annoying.

Scanner sc = new Scanner(System.in);
String answer = sc.nextLine();

if (answer == "yes") {
    System.out.println("Confirmed");
}

You type yes and nothing happens. The == operator checks whether two variables point at the same object in memory, not whether the text matches. It sometimes appears to work with hard-coded strings because Java reuses identical literals, which makes the bug look random.

if ("yes".equals(answer)) {
    System.out.println("Confirmed");
}

Putting the literal first also means a null answer won't crash the comparison. Use equalsIgnoreCase if capitals shouldn't matter.

6. ArrayIndexOutOfBoundsException

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index 3 out of bounds for length 3

int[] marks = {62, 71, 58};
for (int i = 0; i <= marks.length; i++) {
    System.out.println(marks[i]);
}

An array of length 3 has valid positions 0, 1 and 2. The <= lets the loop run one step too far. The message even tells you the bad index and the real length, so read both numbers.

Fix: use i < marks.length, or skip the index altogether with for (int mark : marks).

7. NullPointerException

Student[] group = new Student[3];
System.out.println(group[0].getName());

new Student[3] creates three empty slots, not three students. Calling a method on an empty slot is what throws the exception. The fix is to create the object first, group[0] = new Student("Aisha");. If you want to see how to work through the trace line by line, there's a longer walkthrough on reading a NullPointerException stack trace that goes through the common causes.

8. Scanner skipping a line of input

Scanner sc = new Scanner(System.in);
System.out.print("Age: ");
int age = sc.nextInt();
System.out.print("Name: ");
String name = sc.nextLine();

The program jumps straight past the name prompt and name comes back empty. When you type 21 and press Enter, nextInt() takes the number but leaves the Enter keypress sitting in the buffer. Then nextLine() reads that leftover and returns immediately.

int age = Integer.parseInt(sc.nextLine());
String name = sc.nextLine();

Reading everything with nextLine() and converting afterwards avoids the problem for good.

9. Integer division giving 0

int passed = 7;
int total = 9;
double rate = passed / total;
System.out.println(rate);   // 0.0

Both sides are int, so Java does the division as integers and throws away the remainder before the result ever reaches the double. The type on the left of the = doesn't change how the right side is calculated.

double rate = (double) passed / total;   // 0.7777777777777778

Quick reference

The habit that helps more than any single fix

Most beginners read the error as "something is wrong somewhere" and start editing. The message nearly always gives you a file, a line number and a specific complaint. Read those three things out loud before touching the keyboard. After a few weeks the common errors stop feeling like errors and start feeling like labels, because you'll recognise the pattern before you've finished reading the line.

It also helps to change one thing at a time and recompile. If you fix three things at once and the program works, you won't know which change mattered, and next time the same bug appears you'll be guessing again. That read-first habit is also how Java support at Prime Assignment Help tends to approach debugging with students, going through the message and the line number before touching any code.