Java: Can catch blocks be polymorphic?

Question

In a paper I'm going over for a repeat exam, I'm asked "Can catch blocks be polymorphic?".

If true, it doesn't make sense to me to call multiple catch blocks polymorphic. Is it polymorphism if catch blocks cannot be named and only contain parameters in their method header?

For example:

try {

//...

} catch (FileNotFoundException e) {
    System.err.println("FileNotFoundException: " + e.getMessage());
    throw new SampleException(e);

} catch (IOException e) {
    System.err.println("Caught IOException: " + e.getMessage());
}

In this, are these two catch blocks polymorphic?

I guess it depends on your definition of [polymorphism](http://en.wikipedia.org/wiki/Polymorphism_(computer_science)). — Oliver Charlesworth, Aug 17 '14 at 12:40
You've picked up a strangely specific idea of what it means for something to be polymorphic. There's no reason names would have anything to do with it, for one thing. — user2357112, Aug 17 '14 at 12:42
Wait, are you thinking of method overloading? That can be one form of polymorphism, but it's far from the only kind. — user2357112, Aug 17 '14 at 12:47
@user2357112 Well, I mentioned names because it doesn't seem to be dynamic polymorphism, and I thought static polymorphism was based on names and differing parameters. — DagdA, Aug 17 '14 at 12:57
@whirlwin Yeah, the paper contains a question with multiple true/false questions. One of the other questions was "A final class that implements an interface need not implement all the interfaces [sic] methods". Which could be true or false depending on if a super class implemented the interface's method if I'm not mistaken. Great lecturer. — DagdA, Aug 17 '14 at 13:01

Captain Giraffe · Accepted Answer · 2014-08-17T13:48:01.913

The example you posted should be described as overloading. The only thing different from overloading is a readability requirement that subclasses appears before its superclass.

The statement "Polymorphic catch blocks" requires a bit of gymnastics to parse.

After completing said gymnastics I would interpret it as

A catch block providing a different implementation depending on the type of object being caught.

Something similar to

try{


} catchwith ( catchHandlerObject );

And catchHandlerObject is polymorphic. I.e. handles the same exception differently depending on the (runtime) type of catchHandlerObject.

Is

class C{
   public void m(Object o){ .... };
}

Is m(Object o) polymorphic? I would say that the consensus is that it is unnecessary to include polymorphism in to this description. A call m( stringObject ). is not indicative of polymorphism.

I go contrary to the previous posters an say no. Polymorphic is not the proper way to label this situation. Polymorphism is not the proper way to describe what is happening.

I also really think you should double check this with your TA or your professor. It happens regularly that questions include mistakes ranging from spelling to completely out of mind experiences.

As yshavit noted, overloading indicates a compile time binding. The catch-block is by necessity resolved at runtime. I'm at a loss finding a better term than overloading though.

Hm, I would hesitate to call it overloading, because method overloading in Java is always resolved at compile time; catch clauses are resolved at run time, and in that sense are more similar to polymorphism. Not that they are polymorphic, I agree with you on that. I wouldn't call them by either term. — yshavit, Aug 17 '14 at 13:33
Thanks to you both! My lecturer's on holidays and the exam's tomorrow so I can't ask her. But she's often put unclear questions in the true/false section like "A final class that implements an interface need not implement all the interfaces [sic] methods" which—if I understand correctly—depends on whether or not the unimplemented methods are implemented by a superclass. So I'll just explain the case if any questions like these come up. — DagdA, Aug 17 '14 at 14:04
@PeadarÓDuinnín Indeed both those questions are very unfit for a true/false format, and not well stated. — Captain Giraffe, Aug 17 '14 at 14:06

score 2 · Answer 2 · answered Aug 17 '14 at 12:47

Can catch blocks be polymorphic?

I would answer "yes" to this question, because catch blocks can accept not only the exception that they are declared to catch, but also their direct or indirect subclasses. You do not need multiple catch blocks to show polymorphic behavior - a single block would be sufficient. In fact, you have one of such blocks in your example: it is the last block that catches IOException.

score 2 · Answer 3 · answered Aug 17 '14 at 13:04

2

Effectively, the catch phrase says "Catch any exception which is an instance of this class or a subclass of this class" -- anything that would return true on an instanceof check.

So, by most definitions that would be polymorphic.

answered Aug 17 '14 at 13:04

Hot Licks

47,103
17
93
151

score 1 · Answer 4 · edited Aug 17 '14 at 12:59

If your try block throws an exception that is a FileNotFoundException, or any subclass of FileNotFoundException, then the first catch block will be called.

If your try block throws an exception that is an IOException, or any subclass of IOException that is not FileNotFoundException or a subclass of FileNotFoundException, then the second catch block will be called.

If your try block throws any other exception, none of the catch blocks will be executed.

So, I guess you can say that they are polymorphic, since they accept the type of exception they take as argument, or any subtype of this type.

Java: Can catch blocks be polymorphic?

4 Answers4

Linked