Suppose we have this problem
public class Father{
public void method1(){...}
}
public class Child1 extends Father{
public void method1() throws Exception{
super.method1();
...
}
}
Child1
extends Father
and overrides method1
but given the implementation Child1.method1
now throws a exception. This won't compile as the overriding method can't throw new exceptions.
What is the best solution?
Father
. To me this is against encapsulation, inheritance and general OOP (the Father
potentially throws an exception that will never happen).RuntimeException
instead? This solution won't propagate the Exception
to the Father
, but Oracle docs and other sources state that class of exceptions should be used when "Client code cannot do anything". This is not that case, this exception will be useful to recover blablabla (why is it wrong to use RuntimeException
instead?).Exceptions rule in Inheritance goes like this: "When a subclass overrides a method in super class then subclass method definition can only specify all or subset of exceptions classes in the throws clause of the parent class method(or overridden method)".
Definition: An exception is an event, which occurs during the execution of a program, that disrupts the normal flow of the program's instructions. When an error occurs within a method, the method creates an object and hands it off to the runtime system.
Inheritance is an important pillar of OOP(Object-Oriented Programming). It is the mechanism in java by which one class is allowed to inherit the features(fields and methods) of another class.
In Java, if the constructor of the parent class throws any checked exception, then the child class constructor can throw the same exception or its parent classes. There is no problem if the parent class or child class constructor throws any unchecked exceptions.
Using RTE is not a bad idea. This is the methodology of Spring framework and it works quite fine. If you are implementing application probably use this solution.
If however you are implementing library that exposes API IMHO you should use checked exception. In this case you should create your own exception for example BaseException
. Method method()
of Father
will throw it. The define ChildException extends BaseException
and declare method1()
of child class to throw it.
This does not break encapsulation: base class throws base exception. It does not have any idea about the concrete exception. Child class throws concrete exception that however extends base exception and therefore can be treated by client code as base exception.
As an example I can give you IOException
and FileNotFoundException
that extends it. You can work with input stream catching IOException
while the concrete stream is FileInputStream
and it throws FileNotFoundException
. But client does not know this. It catches IOException
.
Depends on what throws the Exception in Child1. If its some preconditions etc, you can always use any of the subclasses of RuntimeException such as IllegalArgumentException.
However, if there is some sort of CheckedException, then logic suggests that you should handle it that method itself and bubble up the message in some other way.
I think the general rule of thumb is that
if you know how to handle it.. use a checked exception else unchecked exception
If super class method does not declare an Exception then subclass overridden method can not declare checked exception. So you can only use Unchecked exception.
Other option is to allow Super class to declare ParentException
and then child overridden methods can declare any exceptions which are child of ParentException
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With