RPC interface declares throws statement, server side implementation doesn't complain about not having it

[Hans]

Using GWT 2.5.0 and Eclipse Juno I'm declaring a throws RuntimeException inside a method signature.

Thought that this should force implementing methods to declare this as well but Eclipse doesn't complain on not doing so.

Is this by design (of Java and/or GWT)? If so: what's the whole purpose of an interface method declaring a throws statement?

[Hans]

Furthermore, even declaring different throws statements in the interface, the async one and the implementing class doesn't even cause any warning: all by design?

[Hans]

Quick guess: maybe the throws declaration only forces the client to handle the exception?
However it doesn't make sense to throw different exceptions inside the implementation (so they should be bound to the throws decalration in the interface), does it?

[Jens]

When you declare an exception (checked or unchecked) in an interface it means that anyone who uses this interface should be prepared to handle this exception but it does not mean that every implementation of that interface must throw this exception. Maybe an implementation exists that simply do not need to throw it. 

That means when you implement an interface your implementation only have to declare an exception itself when it actually throws this exception. 

The only thing that an interface can enforce is that when declaring a checked exception, all implementations of that interface can not throw more checked exception than the interface has declared. 

Unchecked exceptions (everything thats a RuntimeException) can always be thrown and dont have to be declared at all. If you declare them then its just for information/documentation.

- J.

[Abraham Lin]

This is specified by Java and is by design. The rationale is here: http://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html

-Abraham

[Hans]

Thx for your replies, guys!

By following the link to Orcale's docs I learned that the throws statement belongs to the public interface: "These exceptions are as much a part of that method's programming interface as its parameters and return value." If this was true, the implementation would have to declare the throws statement as defined in the interface.

Nevertheless it's obviously possible to skip the throws clause altogether or to use a different throws statement in the implementing method. So I guess the docs are wrong in this aspect!?

However, I still can't figure out the purpose of a method which implements an interface and declares a throws clause that differs from the interface. Does it only affect clients using the method without using it via the interface?

[Jens]

The docs talk about checked exceptions. These are exceptions that extend Exception and not RuntimeException. A checked exception is part of the API as you can not throw a checked exception without defining a throws clause on a method. Also you must use a try catch block when you want to call a method that throws a checked exception (or re-throw the exception). So if an interface declares such a checked exception all implementations of that interface can AT MOST throw this exception or dont throw an exception at all. If the implementation does not throw the exception at all it also does not have to declared it on its method because the interface has already done so.

Example: 

Imagine a NegativeNumberNotSupportedException extends Exception, so its a checked exception

interface Calculator {

  Integer add(Integer a, Integer b) throws NegativeNumberNotSupportedException;

}

class DumbCalculator implements Calculator {

   Integer add(Integer a, Integer b) throws NegativeNumberNotSupportedException {

      if(a == null || b == null {

          throw new NullPointerException(); //Not declared at all. Thats allowed because its an unchecked RuntimeException.

      }

      if(a < 0 || b < 0) { 

          throw new NegativeNumberNotSupportedException();

          //Must be declared, otherwise you cant throw it. You cant throw any other checked exception than NegativeNumberNotSupportedException because the interface denies it.

      }

      //do calculation with positive integers

   }

}

class IntelligentCalculator implements Calculator {

   Integer add(Integer a, Integer b) {

      if(a == null || b == null {

          throw new NullPointerException(); //Not declared at all. Thats allowed because its an unchecked RuntimeException.

      }

      //do calculation and support negative numbers too! No need to throw anything here, so implementation do not have to declare it. The interface has already declared it as part of its public API.

   }

}

In contrast to checked exceptions you also have unchecked exceptions that extend from RuntimeException (thats what you have used). These can always be thrown everywhere without declaration (see NullPointerException above). If you declare a RuntimeException in a throws clause then its only for documentation. Typically a RuntimeException represents a state the application can not recover from, so its a truly unexpected exception that typically should not occur at all at runtime.

So documentation is not wrong. You just have to differentiate between checked and unchecked exceptions.

For checked exceptions you can not declare different exceptions in the implementation, only the one in the interface are allowed to be re-declared in the implementation. Unchecked exceptions don't have to be declared at all and thus Java does not check (hence the naming "unchecked exception") if the declaration makes sense or not or if you use a try catch block or not.

Obviously you should never use any concrete implementation of Calculator directly (unless you know what you do) as the Calculator interface defines the type and public API. Typically the Calculator is public while its implementations are package private.

-- J.