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 -~----------~----~----~----~------~----~------~--~---