I think I might have caused some confusion by being too lazy: Ex is
meant to be a particular checked exception, not a shorthand for "Exception".
If you are referring to your sneaky throws: I consider them out of
scope. There are many ways to subvert Java code, particularly if
reflection is allowed. If anyone throws a checked exception in code that
was explicitly designed not to throw it (after all that is what the
safe/unsafe distinction is for), then so be it. Java is not strong
enough to stop someone with that attitude from breaking things.
Peter
Reinier Zwitserloot wrote:
> Peter, your code sample is very much broken - exceptions are just
> silently swallowed in the safe version. Sure, you declared that the
> exception can't happen, but as I've mentioned a few times already,
> because checked exceptions aren't enforced on the JVM level, they can
> occur at _any_ time. Therefore, occasionally, such code would swallow
> an exception. No good.
>
> I'm fairly sure that turning every java method into BGGA-style
> "throws" containing generics is going to be just as annoying, if not
> far worse, than the current situation. The problem with checked
> exceptions is that all implementations so far suck far worse than they
> help. I remain convinced that java's checked exception system with an
> explicit command to get around the checked exception system is the
> most practical (though it is of course not the most elegant).
>
>
> On Aug 21, 11:43 am, Peter Becker <peter.becker...@gmail.com> wrote:
>
>> 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
-~----------~----~----~----~------~----~------~--~---
