Chris Gray wrote:
On Sunday 26 March 2006 20:10, Magnusson, Geir wrote:
The point was to illustrate having useful information in the message.
Optime any way you see fit.
That said, given that you are throwing an exception... do we really care?
I'm praying that we don't have apis that throw exceptions as a normal
result of operation.....
java.lang.ClassLoader loadClass() throws a ClassNotFoundException every time a
classloader delegates to its parent and the parent cannot load the class,
which is pretty normal. There's probably plenty more than that - just try
instrumenting a VM to print out all the exceptions thrown in java.lang.* and
watch them fly by ...
Yah, I guess I didn't say what I was really thinking about (I was
walking down the street coming from dinner) which was the performance
overhead of throwing an exception was so large anyway...
I threw together a toy program when I got back to hotel. I called a
method that did a minor amount of work (increment the int arg and return
it). Then I created one that did the same, but then threw an exception.
Then I did one that threw an exception in which string concat was
used. Finally, one that thew an exception in which a StringBuffer was used.
I found, for 5000000 iterations on a 1.86G Pentium M under WinXP using
Sun's 1.4.2_10
C:\dev\eclipse\workspace\playspace\java>java -classpath . SpeedTest
test1 - no exception : 16 millis
test2 - exception, static string: 11859 millis
test3 - exception string concat : 13516 millis
test4 - exception stringbuffert : 14125 millis
C:\dev\eclipse\workspace\playspace\java>java -classpath . SpeedTest
test1 - no exception : 16 millis
test2 - exception, static string: 11594 millis
test3 - exception string concat : 13328 millis
test4 - exception stringbuffert : 13078 millis
C:\dev\eclipse\workspace\playspace\java>java -classpath . SpeedTest
test1 - no exception : 16 millis
test2 - exception, static string: 10812 millis
test3 - exception string concat : 13047 millis
test4 - exception stringbuffert : 13016 millis
So leaving aside the variance from test run to test run, we're seeing
about 74000% overhead due to the exception, and ~20% overhead on top of
static string for using the string concat. (Yes, that's 74,000%)
I guess we don't get much benefit of using stringbuffer to replace only
one concat (or the compiler is smart enough to do that itself anyway...
So to summarize - yes, it's proper to use exceptions, and yes,
performance is crucial, generally speaking, and yes, exceptions are used
for "normal" conditions for code paths (although w/ the number above, I
wonder what the overhead for those 'normal' exceptions are...
So it's a tradeoff. If the exception happens a lot, I agree - make it
fast. But if not, or if we're in the development phase of a library,
make it helpful. Also, maybe we just tag situations like that so we can
go back when the code is stable and optimize...
geir
