your host
Your Host
My RSS Feeds
instanceof vs. ClassCastException
However, i would caveot that with the expectations. If the instanceof check is because you may have a choice to deal with, then its appropriate, though consider refactoring the alternative to moving the decision process to a base class method, if it makes sense to do so, with subclass implementations.
If the situation where it wouldn't be what you expect is extremely rare (but to be expected), then look at the ClassCast exception as a reasonable alternative, only keep in mind where you handle it in order to leave the rest of the code in a safe state.
Another cheap approach is to check classes by name!
if(
myClass.getClass().getName().equals( ... ) )
{
}
So basically what you're saying is to use the ClassCastException in case
something out of the ordinary occurs (an exception). How novel.
Also, I think different JREs handle exceptions differently. I know I saw some big performance differences related to exception handling when I switched from Sun's 1.3.1 JDK to IBM's. Unless you (or "these guys") test using multiple JREs and/or state what platform you/these guys performed your/their tests using then you (collective) wasted your/their (and my) time.
the green mooninite
if( myClass.getClass().getName().equals( ... )
)
{
}
That only works if you're not going to deal with
subclasses, which you in your code shouldn't be sure won't happen. The
whole point of frameworks and OO design is that not only can existing code
be called by code not yet written, but the other way around as well.
As for "mooninite", the point of it was that the java practice that should be followed is to do "the right thing" first, and optimize the exceptions later. Some people in order to "save time" tend to rely on Exceptions even in what should be considered the "normal" case, and that IMHO is a bad thing, because it makes distinguishing between using Exceptions for normal flow-of-control and using Exceptions as they were intended very difficult.
One should strive to write code under the assumption that somebody else besides you, without access to any (likely non-existant) design documents, is going to have to read this code and fix something in it.
Even if that somebody is you, 4-6 months later, and you've forgotten why you did all that you did, only thinking "well, it must have seemed a good idea at the time, but damned if i recall what it was or why..."
You misread the article. The authors did not do tests of instanceof vs.
ClassCastException (or if they did, they didn't report them). They
compiled programs and performed theoretical analysis on the resulting byte
code, but they did not actually perform tests and time the results. Thus
they managed to avoid the problem that instanceof is insanely expensive and
a frequent hotspot, especially compared to cases where the casts succeed.
Not all byte coides execute in equal time.
Elliotte Harold [elharo@metalab.unc.edu]
The idea that it'd be a good idea to do a string comparison of a class name
to avoid an "instanceof" if statement is insane!
You can write String s = new String( "my string" ) all you want, but don't tell others to do it! Sheesh.
Paul