Break Coders Block!

ClassCastException – The most common reason for getting a ClassCastException is because the code in question is accessing an object from a List or Map and casting to an particular class, but the List or Map may have different types of classes. If you are not using generics and allow your List to contain any Object, instead of a specific class type, you’ll get a ClassCastException when you force a cast to one type but the object doesn’t descend from that class. A common fix is use Java generics or to check the type of a class before you force the case using the instanceof operator.

InvalidClassVersion – I’ve seen this exception often when working in a client-server environment. This exception is throw when you have two version of the same class in an environment. For example, maybe you made a large change and recompiled a particular class but only updated the server, the client still has a copy of an much older copy of the class. If objects of this class are serialized and shared between the client and the server you’ll an InvalidClassVersion exception. If a server sends a instance of a class to the client, the client who has an older copy of the class, will throw an InvalidClassVersion error because it’s version of the class may not have the newer methods, method signatures, fields, etc. The client version of the class is simply not compatible with the one in the server. To fix this, make sure that same version of any class is always used.

UnsupportedClassVersionError (Unsupported major.minor version 49.0) – This can happen when you compile an application in a higher version of Java then the version of the Java Virtual Machine in which you run the application. For example, if you compile your application for Java 6 but run the application using Java 1.4.2 you will get an UnsupportedClassVersionError.

NoSuchFieldException – A friend from school just sent me a message as to how to fix a NoSuchFieldException. I thought, just double check the library version, that JavaDocs, the source code, and anything else you can to verify that the field does exist in the class. This exception is thrown because he might be using reflection or some dynamic scripting language such as Groovy or JRuby and has misspelled the name of the field he is trying to invoke. The fix is to double check the API.

NoSuchMethodException – This exception is similar to NoSuchFieldException. You’ll see this exception when working with a dynamic language or when using reflection. When you use Java in a dynamic fashion, such as with Groovy or Java reflection, you don’t get the benefits of static compiled language features. You’ll get errors like NoSuchMethodException at run time instead of catching the error at compile time. It is often caused because you mistyped the name of a function that you want to use.

ClassNotFoundException – This exception can happen because you trying to run a class that references another class that is not in the classpath. Check the classpath and make sure that you have the classes and jars you need for you application to run. ClassNotFoundException often happens when you use third party libraries than themselves require other libraries or jars that you are unaware of.

NullPointerException – A typical Java NullPointerExeption is generally easy to fix with a stack trace of the exception. There is only one case where it is difficult to spot the source of a NullPointerException. The only NullPointerException that will have you baffled is those caused by auto-boxing, such as when you auto-box an Integer object to a primitive int variable. If the Integer object is null and you auto-box it to a primitive int when passing the object to a method whose parameter is an int, you’ll get NullPointerException. But if you look at the line where the exception is thrown, you’ll see that it takes an int and int primitives don’t throw exceptions, so you’ll be scratching your head in confusion until you realize that the calling method used an null value Integer object.