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?
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.
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
.
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.
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.