# Common Java Errors Beginners Make and How to Fix Them Ask someone who has just finished their first Java module what they remember most, and a surprising number will say the red text. Not the syntax or the lectures, but the wall of error messages that appears at 11pm the night before a submission. Most of those errors aren't exotic. A small set of them accounts for the bulk of what beginners run into, they turn up in almost the same form every year, and each one has an ordinary cause once you know how to read the message. The real problem is that compiler messages are written for people who already understand the issue, so they feel hostile when you don't. Students who search for [Java programming assignment help](https://primeassignmenthelp.co.uk/Java-Assignment-Help/) tend to say the same thing: they could fix the bug if someone would just explain what the compiler meant. So this post goes through nine of the most common ones, showing the message, the code that triggers it, and the fix. Everything here runs on a plain JDK, no frameworks needed. ## 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 ```text error: cannot find symbol symbol: variable totl ``` ```java 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 ```text error: incompatible types: possible lossy conversion from double to int ``` ```java 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. ```java 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 ```java 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. ```java } else { return "Fail"; } ``` ## 4\. variable might not have been initialized ```java 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. ```java 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. ```java 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 ```text Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index 3 out of bounds for length 3 ``` ```java 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 ```java 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](https://writeupcafe.com/how-to-fix-a-nullpointerexception-in-java-without-just-guessing) that goes through the common causes. ## 8\. Scanner skipping a line of input ```java 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. ```java 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 ```java 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. ```java double rate = (double) passed / total; // 0.7777777777777778 ``` ## Quick reference | Message or symptom | Usual cause | Quick fix | | --- | --- | --- | | cannot find symbol | Typo or wrong scope | Check spelling and where the variable was declared | | lossy conversion | double assigned to int | Cast, or use Math.round | | missing return statement | A path with no return | Add a final else or return | | might not have been initialized | Variable only set inside an if | Give it a starting value | | String comparison never true | Using == on strings | Use .equals() | | ArrayIndexOutOfBounds | Loop runs one step too far | Use < instead of <= | | NullPointerException | Object never created | Construct it before use | | Scanner skips input | Leftover newline | Read with nextLine() and parse | | Result is 0.0 | Integer division | Cast one side to double | ## 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](https://primeassignmenthelp.co.uk/) tends to approach debugging with students, going through the message and the line number before touching any code.