On Friday, March 25, 2011 12:33:41 PM UTC+1, Josh Berry wrote: > > I asked for an example where you prefer checked because the exception > lets you know you can do something about it. > ... that's what those examples are listing. I noticed you conveniently "forgot" InsufficientFundsException and InvocationTargetException. Feel free to say that these corner cases don't outweigh the bad side of checked exceptions (you'll hear no argument from me on that one), but you just ignored them and then asked me again to list examples, in a rude tone of voice too. I found it offensive. Please mind your tone and definitely don't cherry-pick in a counterargument!
I would think in those > examples, you'd typically just wrap all exceptions to a close or write > in some sort of "Fatal" and throw them up? Because, that is the most > likely scenario I've ever seen in those cases. Seriously, how much > effort are you going to make to close a file that is throwing an > exception? > A lot. I mentioned OutputStream. If OutputStream.close() fails, that's as good as any of the writes failing, as it might be a caching stream, and the close() was simply the first opportunity for flush. This is for example for network connections _definitely_ an expected thing that could happen. Returning a 'fail' return value from .close() would suck, as 99% of all java programmers would ignore it, and thus silently ignore the fact that their entire write out just failed entirely. The action to be taken here is to either use an alternate way to write the data, and failing that, to convey an error to the user / log / etc. This should be done by letting the IOException bubble up (which is why it should be possible to tell the compiler to just let the IOException bubble even if I don't manually 'throws' it, because I can't due to an interface restriction). I'm very much open to the argument that IOException (or whatever Exception .close() would throw) is to be unchecked, but error-via-return-value would suck horrible here. Also, this isn't a very clear cut case of "This exception should have been unchecked". I'm more likely to have an error calling > Integer.parseInt than I am close on a file. Amusingly, one of those > is a runtime exception. :) > As I already mentioned earlier in the thread. We are in vehement agreement regarding the consistency of checked vs. unchecked exceptions in java. Unless, however, you suggest we all start from scratch, we need to deal with it. Which means either (A) an explicit opt-out mechanism, or (B) doing away with the concept of 'checked exception' altogether (they'd all be unchecked). > As for the "forgot to check error code," argument. That criticism > seems more aimed at c style returns where crap like getInt would > return a long. With Either types and proper usage of map/flatMap > (usually in a for comprehension), the errors are easy to propagate up > where they can be dealt with correctly. > map/flatMap/Either/Option for OutputStream.close() would be very very stupid. If you forget to check, which I guarantee the majority will do, you silently eat I/O errors, which is extremely bad. > > I agree that an API that is fully in the realm of Either/Option is > easier to reason about, but people do prefer writing in the realm of > exceptions, it seems. > > > yes, because returning a value from .close() to convey error conditions is a horrible, horrible idea, and the random RuntimeException set (OutOfMemory, NPE and friends) can happen just about everywhere, so if all is to be conveyed with return types, then _EVERY_ _SINGLE_ _METHOD_ would have to do it, at which point you've rebuild the exception mechanic in a really crappy way. Thus (unchecked) exceptions are a given, and once you have them, its less convoluted to use them for more, than to introduce an alternate style that is completely different and the line between "When I should use an Either, and when should I throw an exception" is grey. Which it is. Thus, everything-as-an-exception is superior. I'm not implying either that checked exceptions are good or bad, but I am concluding that error-via-return-value is almost universally a bad idea, especially for the java ecosystem. > I'm glad people were willing to answer the incredible softball. Now > > answer the tough one. Give me an API that has "good use" of checked > exceptions. (As before, I'll let your choices above slide, even > though I know some folks disagree with them.) > I'm not your monkey to order around to dance. A little more courtesy would be nice. In fact, this is really _really_ rude of you to throw in my face. So I'll just repeat the two arguments that you so conveniently decided to exclude in your retort. Don't ask me to list more examples again until you've discussed these two, please, or we'll go in circles all day: > FundsNotSufficientToCoverTransaction, > InvocationTargetException Note that .transferFunds(), a hypothetical method in a banking app (and typically something that isn't open source and thus not something I can point you to without breaking a bunch of NDAs), has a void return method, and failing to handle the "Oh, oops, balance isn't sufficient to cover this one" is a very very very serious error here. I guess it's time for a caveat: I want the ability to explicitly ignore checked exceptions, @SneakyThrows style. If for whatever reason that's off the table, I'd prefer that all exceptions are unchecked. I really don't want anything to do with error-via-return-type APIs. The reasoning here is that in practice, especially in the java ecosystem (and in haskell's and scala's and every other language's too, if they were as widespread and popular as java), library authors tend to make mistakes, library APIs are virtually impossible to change once written, and with 'all exceptions are runtime exceptions', there's no need to make choices, and the pain of an API author making the wrong choice is thus alleviated. Besides, even in a perfect ponies and rainbows world where checked exceptions (or Either + uncheckeds) were done perfectly right by all participants in the ecosystem, the benefit over all-unchecked is marginal to non-existent and we definitely don't live in a ponies and rainbows world. I'm defending checked exceptions here and there because of what I feel are rather specious arguments against it, such as first asking for examples and then ignoring 2 decent ones. -- 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.
