6 Java Exceptions that haunt Java beginners.
(Original) (I am new to both Java and English, so I will be glad to receive criticism and help)
Both before and now, I come across many Java newbies who have a problem with a few common exceptions that I have to explain once again. I believe other Senior Java developers have the same problem trying to help newbies deal with these exceptions. Thus, I wrote this article for my own development. Please feel free to comment on this article or add exceptions to the list below.
This is one of those exceptions, with a message like
“Exception in thread “main” NoClassDefFoundError” , that most new Java developers encounter in the world of Java programming. A beginner writes a program that displays “Hello world!”, goes to the command line, types “java …”, presses enter and BAM! =). And figuring out how to get the program to print “Hello world!” on the monitor, takes some time.
NoClassDefFoundError occurs when the Java Virtual Machine (JVM) tries to access a class at startup time and the class is not found, even though the same class was found at compile time. Most often this exception occurs when trying to execute a program using the "java" command and the classpath is not set properly. Here is a description of the reasons why this exception occurs.
- The class is not available in -classpath.
- The CLASSPATH environment variable has been overridden. You can check its presence and correctness using the Windows command “set”.
The solution to the problem is described in more detail
here.
Moreover, you need to understand the difference between the CLASSPATH environment variable and the interpreter key -classpath. Professionals do not recommend using CLASSPATH. The best way is to pass the -classpath key to the interpreter.
ClassNotFoundException is another exception that becomes a nightmare for a newbie as soon as he starts programming. Interestingly, the average Java developer often
gets confused between ClassNotFoundException and NoClassDefFoundError exceptions . And thus, the difference between these two exceptions remains
one of the most frequently asked questions in interviews for the Junior position .
ClassNotFoundException occurs when the JVM tries to load a specific class and does not find it in the classpath. One of the common places where a new Java developer encounters it for the first time is connecting to a database using the JDBC library. There we will try to load the driver using code like Class.forName("JDBCdriver"). A good article about ClassNotFoundException is
here . Trying to understand the concept of
Java Classloaders is the most effective method to deal with this problem. You can read
how to configure Java classpath in Win/Unix environment . As stated in
the java docs , an exception occurs in the following cases:
- You try to load a class using the Class.forName method and the .class file is not in the classpath. This is the most common scenario of the three listed here.
- When the class loader tries to load a class using the loadClass.
- When the class loader tries to load a class using findSystemClass.
This exception is easier for beginners to understand than the first two. Moreover,
this exception is easily identified because when it occurs, the message about the exception
indicates the line number in the program where it occurred. This exception occurs when the JVM tries to access an object or tries to call a method on an object and receives a null instead of a reference to the object. The Java Doc also states the following reasons:
- Accessing or changing a method on an object that is invalid. (i.e. instead of a reference to a JVM object it gets null)
- Getting the length of an array when it is invalid. (not initialized for example)
- An attempt was made to access a non-existent array element of type Object. (i.e. when, instead of an object reference, the array element contains null)
The simplest method to avoid this exception is to use a non-NULL check. However, sooner or later, this becomes a Java development practice and you will find non-NULL checks everywhere. Interestingly,
inserting non-NULL checks everywhere is not considered good programming style . And the main reason to use non-NULL checking is that the developer wants to pass a null object in case of failure or error. Instead, it is
a good programming practice that programmers should use
to return an empty object, rather than a null value , as the basic logic for how a program will behave in the event of an error. However, adopting this programming practice is more difficult than it seems.
There is a good article about this on our resource.
This is another exception familiar to beginners, which occurs when trying to cast an object to a class that is not a subclass of it. Again, this is fairly easy to understand, identify, and simple to fix. One way to avoid this exception when the object's type is unknown at runtime is to use
"InstanceOf" to check that the object is an instance of a particular class.
This exception is self-explanatory and occurs when the JVM attempts to access an array element with a non-existent index, such as negative (-1) or greater than or equal to the size of the array.
It is quite easy to understand, define and correct . For example, when creating a loop,
for (i = 0; i <= cmd_stack.length; i++) System.out.println(cmd_stack[i]); an exception occurs, because in the array the indexes start from 0, and the length method returns the number of elements, and the number is 1 greater than the value of the last index. Correct use
for (i = 0; i < cmd_stack.length; i++) System.out.println(cmd_stack[i]);
This exception is less common and is fairly easy to understand, identify, and resolve. It occurs when the JVM tries to call a non-existent method, or a method with an invalid argument.
GO TO FULL VERSION