On Fri, Mar 25, 2011 at 5:55 AM, Reinier Zwitserloot <[email protected]> wrote: > wrap-and-throw is vastly superior to 'Oops I forgot to check the error > code'. One will either get your compiler to yell at you until you > acknowledge it, or at least will end up bubbling the error, including useful > logistical data about what and where, to some level that will eventually > handle it as an error / bug (render to user, dump into a log, emit to > terminal, highlight debug stack trace, etc). > So, I don't really understand why its even relevant for me to name an > example here. > nevertheless, can do: OutputStream.close() or OutputStream.write(). > java.lang.reflect.Method.invoke (does not return void, but when I know I'm > calling a void method I'm not going to bother checking the return type - > resulting in the error being ignored if the return type is also used to > ferry an error condition). SomeDbLibrarysTransactionObject.close(). > I'm sure I could make a long long list if I ran some analysis on a bunch of > commonly used APIs.
I asked for an example where you prefer checked because the exception lets you know you can do something about it. 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? 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 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. > So you advocate both Either/Option *and* exceptions. Eh, that's piling on > features for no clear added gain, if you ask me. Now we have to reason As I said, I don't know a single proposal here that does not allow for runtime exceptions. Even Haskel has them, if I'm not mistaken. 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. > FileNotFound, FundsNotSufficientToCoverTransaction, > InvocationTargetException, and yes, even IOException and SQLException. Some > times. Other times the level i'm at is wholly inappropriate to treat these > as checked exceptions so I'd like to opt out. If I can't have opt-out I'd > rather they'd all just be unchecked. 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.) -- 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.
