> > On Thursday, March 24, 2011 5:52:42 PM UTC+1, Josh Berry wrote: > On Thu, Mar 24, 2011 at 11:03 AM, Reinier Zwitserloot > <[email protected]> wrote: > > (A) For any method that would ordinarily return void, this boils down to > > C-style "return error codes". I pray I don't have to explain why this is > far > > far worse compared to exceptions (of either checked or unchecked > variety). > > Give me an example of a void method that has a checked exception that > isn't usually dealt with in the "wrap and throw" style. >
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. > How is it harder now? Especially when you usually have getOr methods > on the Option types. (That is, Option<A> typically has a getOr(A) > > that will return what it holds or an alternative value. Couple this > with a getOrThrow(Exception) and you can easily decide right there > exactly what you will do if you didn't get the value. Or even better, > couple Either with some amazing abstractions out there and suddenly > the problem is much easier to reason about.) > 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 about: Do we do this with an exception, or an Option/Either return value? Multiple styles to accomplish the same thing are bad. (One of the reasons I don't really like checked exceptions and just think it should all be unchecked exceptions, or at the very least, one should be able to opt out of preserving the chain when dealing with checked exceptions, is that it takes away / makes far less relevant the stylistic choice of going with a checked or unchecked exception). > > I'm still waiting for examples of some good usages of checked exceptions. > 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. -- 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.
