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