2

I'm trying to override a method, with throwing an exception:

class A {

    public doSomething(){
        // some of logic
    }

}


class B extends A {

    public doSomething() throws MyCustomizedException {
        try {
             // some of logic
        } catch(ExceptionX ex ) {
             throw new MyCustomizedException(" Some info ", ex);
        }
    }      
}

But I get this compile time error :

Exception MyCustomizedException is not compatible with throws clause in A

The two constraints are :

  • Using the same name of the function and the same arguments if they exist: doSomething()
  • Throwing my customized exception

How can I get rid of the exception?

Thank you a lot.

Mikhail
  • 4,175
  • 15
  • 31
user3169231
  • 257
  • 3
  • 13
  • possible duplicate of [What are reasons for Exceptions not to be compatible with throws clauses?](http://stackoverflow.com/questions/10513374/what-are-reasons-for-exceptions-not-to-be-compatible-with-throws-clauses) – Duncan Jones Jan 24 '14 at 12:55
  • You get a down-vote from me. No evidence of prior research at all. – Duncan Jones Jan 24 '14 at 12:56
  • 4
    You're not trying to *overload* a method (multiple method signatures with the same name) you're trying to *override* a method. – Jon Skeet Jan 24 '14 at 12:56
  • But it seems that overloading by throwing an exception is not allowed. Only adding an argument or changing its type would be admitted... right? – user3169231 Jan 24 '14 at 13:00
  • possible duplicate of [Method overriding in Java throwing exceptions](http://stackoverflow.com/questions/11332684/method-overriding-in-java-throwing-exceptions) – Raedwald Jan 24 '14 at 13:02
  • You can only narrow exceptions during inheritance and overriding. How about overloading doSomething method, sth like doSomething(int a) and then call doSomething() inside your overloaded method and throw your exception? That should work! – small_ticket Jan 24 '14 at 13:38

4 Answers4

7

Cannot be done.

When you override a method, you can't break the original contract and decide to throw a checked exception.

You can make MyCustomizedException unchecked. You can throw it, but you can't require that users handle it the way you can with a checked exception. The best you can do is add it to the javadocs and explain.

duffymo
  • 305,152
  • 44
  • 369
  • 561
2

There is actually a way to do this - using composition rather than inheritance:

class B {
   A a = new A();
   void doSomething() throws MyException {
      a.doSomething();
      throw MyException();
   }
}

Of course by doing this your B no longer counts as an A so cannot be passed to anything expecting an A. You could use a B throughout your code though and just wrap As on demand.

Tim B
  • 40,716
  • 16
  • 83
  • 128
  • You lost IS-A and polymorphism. Liskov Substitution Principle won't let you use a B wherever you have an A. – duffymo Jan 24 '14 at 13:37
  • @duffymo Of course. In fact my answer says that in the last sentence. If the OP doesn't need B to count as an A though (which is possible depending on what they are doing with the library, what A and B are, etc) then it solves the problem. – Tim B Jan 24 '14 at 16:52
  • An interface is one way to maintain substitutability. using `interface DoerOfThings{ void doSomething(); }`, classes `A` and `B` can both implement `DoerOfThings` and `B` can even use `A` to implement the interface by composition. Of course the more members of the interface, the more boilerplate `B` must contain to reuse `A`'s implementation. – Michael Hoffmann Apr 08 '20 at 06:56
0

This is not a overloading case. To overload you need methods with same signature but different argument list. This is Overriding, Use public doSomething() throws MyCustomizedException {} in class A if Class A can modify.

Now you can override with your current implementation for class B.

Ruchira Gayan Ranaweera
  • 34,993
  • 17
  • 75
  • 115
0

The only way you can do this is to make the exception that you are throwing extend RuntimeException instead of Exception.

This way you will be able to throw it as you don't change the compact of the method, unfortunately the compiler will not automatically detect that you need to catch that exception but depending on how you are using it that may not be a problem.

Tim B
  • 40,716
  • 16
  • 83
  • 128