It's not out of band, Peter - this stuff happens, in real life, even if you never explicitly accepted the burden of responsibility by e.g. using @SneakyThrows. Just mixing class files compiled against different versions of the same code base is enough to get there. Thus, you *CANNOT* just swallow exceptions. I was not referring to your 'Ex' as standing specifically for java.lang.Exception - it doesn't matter what exception class it stands for. Swallowing an exception automatically behind the scenes is not acceptable. At the very least wrap it up (not my preferred solution, certainly, but better than swallowing it).
On Aug 22, 11:53 am, Peter Becker <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 <[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 -~----------~----~----~----~------~----~------~--~---
