As I said: in cases where you want to have a version of your code where
the exception bubbles up and one where it doesn't you'll get the
duplication. I think that is usually a bad idea, although I must admit
the wrapper case you describe is an exception since the layer is the
same. I don't see that problem spread too far, though.
If your code is really that big, I'd even consider this:
public class UnsafeWrapper implements UnsafeInterface {
protected UnsafeInterface orig;
...
public doAction() throws Ex {
...
orig.doAction();
....
}
}
public class SafeWrapper implements SafeInterface {
...
public doAction() {
...
try {
orig.doAction(); // call on UnsafeWrapper.doAction()
} catch(Ex e) {
// won't happen
}
}
}
Not very elegant, but avoids major duplication.
I believe that with union types the whole problem would disappear since
the subtyping would allow using generics to create the different
versions. As long as exceptions are not part of the type signature it
won't happen in Java.
Peter
Reinier Zwitserloot wrote:
> Peter, I still don't see how that'll avoid code duplication.
>
> Let's say, for argument's sake, that a FilterInputStream's read()
> method contains 4 pages of complex code. This code calls back into the
> filtered stream's read method loads of times. How would we avoid
> duplicating these 4 pages if we want 2 types of FilterInputStream: One
> that wraps a Safe InputStream and does not throw IOException, and one
> that wraps an unsafe InputStream and does throw IOException.
>
> On Aug 20, 9:36 am, Peter Becker <peter.becker...@gmail.com> wrote:
>
>> 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 <peter.becker...@gmail.com> 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 javaposse@googlegroups.com
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
