REUSING EXCEPTIONS
When an exceptional condition occurs in a program, it's typical to throw an exception. The syntax for
throwing an exception often looks something like this:
throw new MyException("String");
Literally, you create the exception when the exceptional condition happens, and immediately throw it
to the caller (or to some enclosing try-catch block).
If you print a stack trace at that point with printStackTrace(), the information you see is filled with
the details of the stack at the time the exception was created. This might sound obvious. However, if
you want to avoid creating new objects when an exception occurs, you can create the exception once,
and reuse it when the exceptional condition reoccurs. A common design pattern for this is called a
Singleton. You can create the object the first time you need it, and then keep reusing the same object.
For example:
MyObject myObject = null;
private synchronized MyObject getMyObject() {
if (myObject == null) {
myObject = new MyObject();
}
return myObject;
}
What happens if you use a pattern similar to this with an Exception object (or in fact anything that
subclasses java.lang.Throwable)? In this case, the stack trace is filled with the trace from when the
exception was created. Typically, that isn't what you want because you probably want to see the exact
trace for each exception, that is, when each exception happened. In order to share exception objects in
this way, you have to refill the stack trace for the new stack when the exception happens. The method
of Throwable to do this is fillInStackTrace.
Here's what the getMyObject pattern looks like after adjusting it to work with exception objects:
MyExceptionObject myExceptionObject = null;
private synchronized MyExceptionObject
getMyExceptionObject() {
if (myExceptionObject == null) {
myExceptionObject = new MyExceptionObject();
} else {
myExceptionObject.fillInStackTrace();
}
return myExceptionObject;
}
Notice that you don't have to fill in the stack manually the first time. It's done for you. You only have to
fill in the stack for subsequent occurrences.
At this point, you might ask why you would want to reuse exception objects. One reason to reuse (or
even just pre-create) exception objects is to minimize the number of objects created when an exception
actually happens. Of course, filling the stack does take resources, so this isn't completely free of the
need for memory resources. And, if you truly don't need the stack trace, this pattern allows you to not
bother filling it.
To demonstrate this behavior, the following program shows two ways of reusing exception objects. For
each approach, the exception is printed three times. In the first case, the same stack is shown three
times, even though three different methods print the trace. The latter case demonstrates the difference
in each stack when you refill the stack trace with each call.
import java.io.*;
public class ReuseException {
IOException exception1 = null;
private synchronized IOException
getException1() {
if (exception1 == null) {
exception1 = new IOException();
}
return exception1;
}
IOException exception2 = null;
private synchronized IOException
getException2() {
if (exception2 == null) {
exception2 = new IOException();
} else {
exception2.fillInStackTrace();
}
return exception2;
}
void exception1Method1() {
getException1().printStackTrace();
}
void exception1Method2() {
getException1().printStackTrace();
}
void exception1Method3() {
getException1().printStackTrace();
}
void exception2Method1() {
getException2().printStackTrace();
}
void exception2Method2() {
getException2().printStackTrace();
}
void exception2Method3() {
getException2().printStackTrace();
}
public static void main(String[] args) {
ReuseException reuse =
new ReuseException();
reuse.exception1Method1();
reuse.exception1Method2();
reuse.exception1Method3();
System.out.println("---");
reuse.exception2Method1();
reuse.exception2Method2();
reuse.exception2Method3();
}
}
When you run the program, your output should look something like this:
java.io.IOException
at ReuseException.getException1
(ReuseException.java:9)
at ReuseException.exception1Method1
(ReuseException.java:26)
at ReuseException.main
(ReuseException.java:51)
java.io.IOException
at ReuseException.getException1
(ReuseException.java:9)
at ReuseException.exception1Method1
(ReuseException.java:26)
at ReuseException.main
(ReuseException.java:51)
java.io.IOException
at ReuseException.getException1
(ReuseException.java:9)
at ReuseException.exception1Method1
(ReuseException.java:26)
at ReuseException.main
(ReuseException.java:51)
---
java.io.IOException
at ReuseException.getException2
(ReuseException.java:18)
at ReuseException.exception2Method1
(ReuseException.java:38)
at ReuseException.main
(ReuseException.java:55)
java.io.IOException
at ReuseException.getException2
(ReuseException.java:20)
at ReuseException.exception2Method2
(ReuseException.java:42)
at ReuseException.main
(ReuseException.java:56)
java.io.IOException
at ReuseException.getException2
(ReuseException.java:20)
at ReuseException.exception2Method3
(ReuseException.java:46)
at ReuseException.main
(ReuseException.java:57)
For more information about working with exceptions, see the lesson "Handling Errors with Exceptions"
in the Java Tutorial. Also see the documentation for the Throwable class.
back to top
Reader Feedback
Very worth reading Worth reading Not worth reading
If you have other comments or ideas for future technical tips, please type them here:
Have a question about Java programming? Use Java Online Support.
back to top
IMPORTANT: Please read our Terms of Use, Privacy, and Licensing policies:
http://www.sun.com/share/text/termsofuse.html
http://www.sun.com/privacy/
http://developer.java.sun.com/berkeley_license.html
Comments? Send your feedback on the Core Java Technologies Tech Tips to: [email protected]
Subscribe to other Java developer Tech Tips:
- Enterprise Java Technologies Tech Tips. Get tips on using enterprise Java technologies and APIs,
such as those in the Java 2 Platform, Enterprise Edition (J2EE).
- Wireless Developer Tech Tips. Get tips on using wireless Java technologies and APIs, such as those
in the Java 2 Platform, Micro Edition (J2ME).
To subscribe to these and other JDC publications:
- Go to the JDC Newsletters and Publications page, choose the newsletters you want to subscribe to and
click "Update".
- To unsubscribe, go to the subscriptions page, uncheck the appropriate checkbox, and click "Update".
ARCHIVES: You'll find the Core Java Technologies Tech Tips archives at:
http://java.sun.com/jdc/TechTips/index.html
Copyright 2003 Sun Microsystems, Inc. All rights reserved.
4150 Network Circle, Santa Clara, CA 95054 USA.
This document is protected by copyright. For more information, see:
http://java.sun.com/jdc/copyright.html
Java, J2SE, J2EE, J2ME, and all Java-based marks are trademarks or registered trademarks
(http://www.sun.com/suntrademarks/) of Sun Microsystems, Inc. in the United States and other
countries.
