Exception transparency - lone throws (no checked exceptions)

[Alex Blewitt]

On 10 Jun 2010, at 15:08, Stephen Colebourne <scolebourne at joda.org>  
wrote:

> So, here is how it would work:
>
>  public void process() throws {
>    throws new IOException();
>  }
>
>  public void worker() {
>   process();   // can catch IOException here if we want
>  }
>
>  public void master() {
>   worker();   // cannot catch IOException here
>  }

How could this work in the face of subclasing? What if there's an  
interface or abstract method with a lone throws? What if there are two  
implementers which throw different (distinct) exceptions? What if I  
invoke that abstract method - what types am I expecting to catch?

I also don't see how this works in the transitive closure case, with a  
calling b and b calling c (different files) and c throws IOException.  
At (first) compile time, the lone throws of a and b will have  
IOException added to the list.

If you then change c to throw a new set of exceptions (say, adding  
java.sql.SQLException) then the throws of b and a need to be updated.  
With the line throws, the complier will have to compile potentially  
every call path to that point again.

Alex