Sneaky sounds like it might be part of some dynamic language and can't be trusted. :) Perhaps something like 'enforced propagation'. That sounds more intimidating. :)
On Jun 6, 7:43 am, Reinier Zwitserloot <reini...@gmail.com> wrote: > Oh, crap. I so failed at naming this thing. I'll mail you next time I > have a proposal and can't think of a name :P > > On Jun 5, 10:56 am, Christian Catchpole <christ...@catchpole.net> > wrote: > > > Perhaps sneakyThrows just needed a better name. Like ElvisThrows (the > > exception has left the building). Because it turns up unexpectedly in > > an Ohio 7/11. > > > On Jun 5, 5:19 pm, Reinier Zwitserloot <reini...@gmail.com> wrote: > > > > Christian, I think the issue 'there's nothing you can do' is trying to > > > make a different point. > > > > In my book, having to handle an exception when you don't want to is a - > > > really- -bad- thing. Due to badly designed interfaces (such as > > > java.lang.Runnable, for example), you sometimes cannot just stick a > > > 'throws IOException' on your method, even though you know there is no > > > actual problem if you throw the exception onwards. In other > > > situations, IOExceptions are declared to be thrown by many methods > > > that cannot actually -EVER-, --EVER--, happen, or at least, if they do > > > happen, its on the level of OutOfMemoryErrors: i.e. sufficiently rare > > > that letting an unexpected exception escape from your method is just > > > fine. Contrast this to C land, where unexpected stuff generally > > > results in core dumps, so we're still getting nice effects from > > > exceptions here. > > > > To wit: > > > > - new String(byteArray, "UTF-8"); > > > > - new ByteArrayOutputStream(); // do stuff with it - throws > > > iOExceptions according to declaration, but we know it can't happen. > > > > - All InputStream.close() calls. > > > > So, that's a -very- significant amount of code where you wish > > > IOExceptions were unchecked; either you know the caller can handle > > > them just fine but you can't throw them due to interface restrictions > > > (and with java's "We don't change anything due to backwards > > > compatibility", the argument 'then you should design your APIs better" > > > is disingenuous!), or because you know they really really really can't > > > happen (similar API design argument available here, and disingenuous > > > for similar reasons). > > > > There's a threshold of 'checked exception failure' - where the > > > compiler's good intentions in helping you remember to handle the > > > exceptions is just getting in the way, which is around 5 to 10%, in my > > > book. If the checked exception is just wrong more often than that, the > > > aggravating outweighs the very minor convenience of having the > > > compiler tell you. > > > > The reason its a minor convenience is for the obvious nature of it: > > > When I am doing file I/O, I'm fairly sure I'm going to remember things > > > COULD go wrong. When I parse user input into a number, I'm fairly sure > > > the user may not have supplied a number, so NumberFormatException is > > > *unchecked*. And yet the number of times I run into a program to > > > forgot to catch that exception, is countable on one hand. > > > > NB: For what it's worth, I suggested an elegant workaround for these > > > issues for project coin: allow a method to declare sneakyThrows in > > > addition to throws. The *ONLY* difference between throws and > > > sneakyThrows is that sneakyThrows is *NOT* part of the method > > > signature. e.g. if you sneakyThrow UnsupportedEncodingException, then > > > if your method body throws that exception, it'll bubble up as usual > > > (will not get wrapped into a RuntimeException), but, callers do not > > > need to handle it. This is not complicated, because the JVM already > > > works like this. It's javac that refuses this situation at the moment, > > > not the jvm. Scala and friends work as if every method had > > > 'sneakyThrows Throwable' on them. So, a trivial change, at least > > > implementation wise. > > > > This proposal got villified, torched, hung, drawn, quartered, and > > > pooped on. No, really. I was likened to a grave criminal. Eh, I tried. > > > > On Jun 5, 1:03 am, Christian Catchpole <christ...@catchpole.net> > > > wrote: > > > > > I don't want to turn this into a checked vs non-checked debate. But > > > > I'm glad we are having this discussion, as I was recently reading a > > > > checked vs non-checked article. It was well thought out for the most > > > > part but it argued that IOExceptions should not be checked because > > > > when an error occurs "there is nothing you can do about it". This > > > > trivializes matters. And sure, if your socket gets closed or someone > > > > unplugs their USB stick, sure there may not be much you can do about > > > > it. But to claim the exception should just bubble up to bash ignores > > > > the kinds of resource allocation issues we are discussing here. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
