Disadvantages of "instanceof"

[Mark Sizzler]

As far as I know one should not use the operator "instanceof" if possible.

Why?

Mark

 

[xarax]

As far as I know one should not use the operator "instanceof" if possible.

Why?

I only use "instanceof" when I am not the author
of the classes for which I am testing. If I am
the author, then I can use built-in down-casting
by the JVM for free. If the classes are "foreign",
then I'm stuck using "instanceof".

Example: I am catching an IOException, but I want
to test for a particular subclass to know what
exactly went wrong. I didn't author the classes nor
did I instantiate the reference, so I must use
"instanceof".

On the other hand, when I am the author of the
classes, then I know all of the possible subclasses
and I can design them so that I don't need to use
"instanceof" to decide how to downcast to the specific
type. I can just use the built-in down-casting feature
of the JVM.

On a different note, the new generics feature of
JDK 1.5 makes down-casting less needed.

A properly implemented JVM can execute "instanceof"
and down-casting in constant time.

The use of "instanceof" is generally frowned upon,
because it means there is a weakness in the object
oriented (polymorphic) design of the code that needs
it.

 

[Ryan Stewart]

I only use "instanceof" when I am not the author
of the classes for which I am testing. If I am
the author, then I can use built-in down-casting
by the JVM for free. If the classes are "foreign",
then I'm stuck using "instanceof".

Example: I am catching an IOException, but I want
to test for a particular subclass to know what
exactly went wrong. I didn't author the classes nor
did I instantiate the reference, so I must use
"instanceof".

[...]
Why not use multiple catch blocks? That's why they're available.

 

[Tilman Bohn]

I only use "instanceof" when I am not the author
of the classes for which I am testing. If I am
the author, then I can use built-in down-casting
by the JVM for free. If the classes are "foreign",
then I'm stuck using "instanceof".

Example: I am catching an IOException, but I want
to test for a particular subclass to know what
exactly went wrong. I didn't author the classes nor
did I instantiate the reference, so I must use
"instanceof".

[...]
Why not use multiple catch blocks? That's why they're available.

Also, I fail to see how this would be affected by whether or not
the exception-throwing code is under my control...?

 

[Antti S. Brax]

Please set the Followup-To header when crossposting.

[...]
Why not use multiple catch blocks? That's why they're available.

Also, I fail to see how this would be affected by whether or not
the exception-throwing code is under my control...?

Maybe this example helps? You can replace the call to foo()
with a method the exception-throwing code of which you do not
control (as long as you know that it can throw an EOFException).

import java.io.*;
public class Test {
public static void foo() throws IOException {
throw new EOFException("eof");
}
public static void main(String[] args) {
try {
foo();
} catch (EOFException ex) {
System.err.println("EOFException: " + ex.getMessage());
} catch (IOException ex) {
System.err.println("IOException: " + ex.getMessage());
}
}
}

 

[Tilman Bohn]

Please set the Followup-To header when crossposting.

Please refrain from assuming that if someone doesn't adhere to your
precise idea of netiquette they do so without having given it any
thought. The OP x-posted to help and programmer, with f'up2 set to help
(not an unreasonable thing to do, IMO). As you can see for yourself, in
my one direct followup to the OP I honored this, and it went only to
help. However, the two (I think) posters preceding me in _this_
particular sub-thread, for some reason unknown to me, did not, and kept
x-posting to both groups. As two groups to me is still within the limits
of acceptability, and the thread is not OT in either group, I kept them
both in this case. Note, however, that I'm honoring _your_ f'up2, even
though I'd say that if I had to choose one of the two, the OP's choice
would be much more appropriate.

[...]

Maybe this example helps? You can replace the call to foo()
with a method the exception-throwing code of which you do not
control (as long as you know that it can throw an EOFException).

[...]

And exactly how would you do this differently if foo() _was_ under
your control?

 

[Antti S. Brax]

Maybe this example helps? You can replace the call to foo()
with a method the exception-throwing code of which you do not
control (as long as you know that it can throw an EOFException).

[...]

And exactly how would you do this differently if foo() _was_ under
your control?

I would declare all the thrown exceptions in the trows clause
of the method. If the method never throws a pure IOException
I propably would not include it in the throws clause.

But that was not the point I was going after. I was showing a
way to do the exception handling without using instanceof.

 

[Tilman Bohn]

In message <[email protected]>,
Antti S. Brax wrote on 18 Feb 2005 07:09:57 GMT:

[...]

I would declare all the thrown exceptions in the trows clause
of the method. If the method never throws a pure IOException
I propably would not include it in the throws clause.

How does that influence your use or non-use of instanceof in your
catch claus(es)?

But that was not the point I was going after. I was showing a
way to do the exception handling without using instanceof.

But why are you making this point to me? I already know that, and it's
not under discussion here. The starting point of this thread was xarax's
statement that

I only use "instanceof" when I am not the author
of the classes for which I am testing. If I am
the author, then I can use built-in down-casting
by the JVM for free. If the classes are "foreign",
then I'm stuck using "instanceof".

followed by the catch (IOException) example.

(In <
To which Ryan said,

Why not use multiple catch blocks? That's why they're available.

(In <[email protected]>.)

To which I finally said, that not only that, but I also failed to see
how having control of the other classes would make a difference in
whether or not to use instanceof in the error handling. And frankly, I
still don't see the difference. Either you know what to expect, or you
don't. It would seem to me you can catch any exception explicitly that
you can check for with instanceof, whether the exception-throwing method
declares it or not. Or am I missing something here?