Here you go (three files):

===== test/Unsafe.java======
package test;

import java.io.IOException;

public interface Unsafe {
    void method() throws IOException;
}

===== test/Safe.java ======
package test;

public interface Safe extends Unsafe {
    void method();
}

=====test/Test.java=======
package test;

import java.io.IOException;

public class Test {
    class UnsafeImpl implements Unsafe {
        @Override
        public void method() throws IOException {
            throw new IOException(); // ok
        }
    };

    class SafeImpl implements Safe {
        @Override
        public void method() {
            // can't throw here
        }
    };

    void method1(Unsafe unsafe) {
        unsafe.method(); // error, need to deal with exception
    }

    void method2(Safe safe) {
        safe.method(); // ok
    }
}

==========

The one trick is to realize that the safe version is actually the more 
specific one. If you think of the exception in terms of the type union 
(not accurate, but a decent analogy), then Unsafe.method() returns 
void|IOException while Safe.method() returns void, which is a more 
specific type, thus the return types are co-variant.

More generally you can argue that Safe.method() makes stronger 
guarantees about its behavior than Unsafe.method(), so subtyping is 
legal. Apart from the one marked position the code above is legal Java.

  Peter


Reinier Zwitserloot wrote:
> On Aug 20, 12:21 am, Peter Becker <[email protected]> wrote:
>   
>> No implementation would be duplicated, the safe version could be a
>> subtype of the unsafe one. Not too many interfaces will face that
>> problem. To me it seems much better than not distinguishing.
>>     
>
> Can you show me how this would work?
>
> I have a hard time seeing how you can do that without (oh, the irony),
> employing some sort of sneakythrow mechanism.
>
> I guess we will have to agree to disagree here, but I'm fairly sure
> the idealism lost in allowing sneakythrow is minor, whereas the amount
> of pain you can solve is sizable. (in practice, due to widespread bad
> API design we all know will never ever get fixed, such as in the core
> JDK)
>
> >
>   



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to