Making a readable Stack Trace
To get a more readable printout we'll do this:
- for each exception thrown we'll list its class name and
message (using toString).
- for each exception thrown we'll print the first line from the
stacktrace
- for the last exception thrown we'll list the complete
traceback. This will give us the line numbers of the full chain
of method calls
The modified version of printExceptionChain looks like this:
private static void printExceptionChain(Throwable thr) {
StackTraceElement[] s;
Throwable t = thr;
System.out.println("Exception chain (top to bottom):");
while (t != null) {
System.out.println("-------------------------------");
s = t.getStackTrace();
StackTraceElement s0 = s[0];
System.out.println(t.toString());
System.out.println(" at " + s0.toString());
if (t.getCause() == null) {
System.out.println("-------------------------------");
System.out.println("Complete traceback (bottom to top):");
t.printStackTrace();
}
t = t.getCause();
}
}
This time we get this printout:
Exception chain (top to bottom):
-------------------------------
java.lang.RuntimeException: w contains []
at hansen.playground.GetMean4.mean(GetMean4.java:40)
-------------------------------
java.lang.RuntimeException: Division by zero
at hansen.playground.GetMean4.divide(GetMean4.java:51)
-------------------------------
Complete traceback (bottom to top):
java.lang.RuntimeException: Division by zero
at hansen.playground.GetMean4.divide(GetMean4.java:51)
at hansen.playground.GetMean4.mean(GetMean4.java:38)
at hansen.playground.GetMean4.main(GetMean4.java:9)
The complete program is found
here.
Checked or Unchecked Exceptions?
Every Java programmer has an opinion of what kind of exceptions
to use: checked or unchecked. Discussions about this topic can
tend to be somewhat religious. For a long time I've been on the
"checked exceptions" team, but lately I've started to lean more
towards the unchecked variety. If you are in a situation where
you must select among the two alternatives you should consider
this:
If you use checked exceptions in a method, you force the caller
to handle the exception or propagate it to his caller. A relevant
question is now: Does the caller know what to do? Often he
doesn't, and therefore there's a risk that the caller will simply
suppress the exception, leaving the application in an unknown
state, which often will cause a system crash some time later,
with a bug that might be very hard to find.
The caller will also very often simply propagate the exception to
his caller, which again will do the same thing to his caller etc.
If this is the case then an unchecked exception will work just as
well.
If you're working in a team developing a non-trivial application
it's mandatory to have decided upon a standard for error handling.
It'll greatly improve the robustness of the application, it'll
save development time, and later on ease maintenance (bug finding
and updates). My advice on such a standard would be:
- use chained exceptions, using the technique described in this
article
- let the exception be unchecked (e.g. RuntimeException)
- let the caller use try-catch if he has some useful data to
add to the error description
- let the caller skip the try-catch if there is no important
data to add (the exception will not be lost - it'll propagate up
the calling chain and will eventually be caught by someone - a
common error handler - or at least by the VM)
Don't forget that part of the standard is to document the standard!
Conclusion
By using the chained exception feature in JDK 1.4 we're able to
produce a quality error report with this
information:
For each method call:
- the name of the exception
- the names of the class and method
- the line number for the failing method call
- the line number for the throw statement
- a message containing relevant data
and a complete method call traceback (as in the older JDKs).
If the message data has been carefully selected to contain data
relevant for the error situation then the error report will be of
great value in pinpointing the cause of the error.
Resources
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
| 
