Casting vs reflection as flowcontrol

Question

I remember having read somewhere, that casting shouldnt be used to control the flow of statements. I just did some testing, calling a method with code like this:
try {
SomeObject b = (SomeObject)object;
doSomething(b);
} catch (ClassCastException f) {}
vs.
if(SomeObjectClass.isInstance(object)) doSomething(b);
and it turned out the casting was faster even in cases where an exception was thrown. Could someone explain this. Is my use of reflection wrong?
Stig.

Answer 1

Did you try running the test with perhaps 1,000,000
iterations?Testing the successful cast with 100,000,000 iterations yielded the following results:
Successful cast... 5407ms
Successful test... 6540ms
Successful cast... 6920ms
Successful test... 7901ms
Successful cast... 6920ms
Successful test... 7901ms
Successful cast... 6940ms
Successful test... 7902ms
Successful cast... 6920ms
Successful test... 7851ms
For some reason JIT performance degraded, even though the test calls the same method (which performs the test/cast) in each case.
Testing before casting consistently runs 13% slower than only casting. Having said that, the following figures also imply that each instanceof test took approximately 9.6x10^(-6) milliseconds. That's 10 nanoseconds each test, or 100,000 tests each millisecond. I doubt this would form the bottleneck for any system that actually does anything.
Just for completeness, the times for the unsuccessful cast with only 100,000 iterations yielded:
Unsuccessful cast... 4657ms
Unsuccessful test... 10ms
Unsuccessful cast... 4597ms
Unsuccessful test... 0ms
Unsuccessful cast... 4516ms
Unsuccessful test... 0ms
Unsuccessful cast... 4527ms
Unsuccessful test... 10ms
Unsuccessful cast... 4466ms
Unsuccessful test... 10ms
I don't know what the proportion is here, since the time required for the unsuccessful test is obviously not accurate enough, but I didn't think an exact proportion was called for :-)
If there is a reasonable chance that the cast will be unsuccessful, it is no longer an exceptional case... which suggests that using exceptions is no longer appropriate, in terms of design if not in terms of performance.