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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > > 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 [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 -~----------~----~----~----~------~----~------~--~---
