Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Standard Edition >

Exceptions: Don't get thrown for a loss

Catch the differences between checked and runtime exceptions

By Tony Sintes, JavaWorld.com, 02/08/02

  • Print
  • Feedback
.

February 8, 2002

Q Please explain the difference between checked exceptions and runtime exceptions? When would I throw them, and when would I catch them?

A Java provides two main exception types: runtime exceptions and checked exceptions. All checked exceptions extend from java.lang.Exception, while runtime exceptions extend from either java.lang.RuntimeException or java.lang.Error.

Two aspects differentiate checked exceptions from runtime exceptions: mechanical and logical.

The mechanics

From a mechanical viewpoint, runtime exceptions and checked exceptions differ in how you declare the method that throws the exception, and how you handle the exception when it's thrown. Consider the following checked exception definition: 

public class CheckedException extends Exception {
public CheckedException() {}
public CheckedException( String message ) { super( message ); }
}


The following class has a number of methods that throw exceptions:

public class ExceptionalClass {
public void method1() throws CheckedException {
        // ... some code
        throw new CheckedException( "something bad happened" );
}
    public void method2( String arg ) {
        if( arg == null ) {
            throw new NullPointerException( "arg passed to method2 is null" );
}   
}
public void method3() throws CheckedException {
    method1();
}
}


Right away you'll notice that both method1() and method2() throw exceptions, but only method1() has an exception declaration. You'll also notice that method3() doesn't throw an exception itself, but its signature indicates that it may throw a CheckedException. Before I tell you why, consider the following main method: 

public static void main( String [] args ) {
    ExceptionalClass example = new ExceptionalClass();
    try
    {
        example.method1();
        example.method3();
    }
    catch( CheckedException ex ) {
    }
    example.method2( null );
}


When a call is made to method1(), you must make the call from within a try/catch block. In this case, it's a checked exception because you must catch it. Checked exceptions are always declared as thrown in the method signature. The signature lets the method's caller know that an exception may occur as a consequence of the call. If the exception does get thrown, the caller must be prepared to do something about it.

Contrast method1() with method2(). When you make a call to method2(), you don't have to do so within a try/catch block. Since you do not have to catch the exception, the exception is said to be unchecked; it is a runtime exception. A method that throws a runtime exception need not declare the exception in its signature.

Now, look back at method3(). It makes a call to method1() without making the call in a try/catch block. method3() avoids not catching the exception by declaring that it may also throw the exception thrown by method1(). Instead of catching the exception, method3() simply passes the exception along. Analogously, you could have dispensed with the try/catch block in the main method by declaring that it throws CheckedException. (I only mention this to give you a second reference point; you should never declare a main as throwing an exception.)

  • Print
  • Feedback

Resources