Ben Schulz wrote:
>> 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.
>>
>
> I think Reinier was refering to this:
>
> x.doSomething(new StringReader("xyz"));
> x.doSomething(someUnsafeReader());
>
> Unless you have two overloads of doSomething both invocations will
> throw an IOException. Having two overloads is code duplication though.
> Even if it looks like that:
>
> public void doSomething(SafeReader r) {
> try {
> doSomething((UnsafeReader)r);
> } catch(IOException e) {
> throw new RuntimeException(e);
> }
> }
>
Here's my version of the story:
If you are happy to deal with the exception, then just write the version
for the UnsafeReader which will take SafeReader implementations.
If you don't want to allow the exceptions, write the SafeReader version
only.
If you feel the need to pass the exceptions through without dealing with
them (not even wrapping them into an exception suitable for your layer),
then you are probably creating a leaky abstraction.
But I agree that this pattern could not easily be retrofitted into the
JDK or other code.
Peter
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
