They are NOT the reason that lambda is delayed. The current plan for lambda, which is target-typing to SAMs, has absolutely no problem with checked exceptions.
On Sep 22, 12:07 am, Kevin Wright <[email protected]> wrote: > I totally abhor checked exceptions, although the concept has a lot going for > it they just cause too many problems. > > they: > - increase coupling between units > - create test paths that are often challenging to get coverage for > - invite API users to swallow them or log them at an inappropriate time > (often several times) > - encourage a poor coding style where an exception is used as an alternate > return path for a condition that isn't all that exceptional > - complicate the control flow that has to be understood when reading a piece > of code > - add boilerplate (as though Java needed more of *that*) > - are quite possibly the reason why lambdas couldn't be finished in time for > Java 7 > > The typical use-case for me is that when I call a function that may throw an > exception, I usually can't respond to it in any sane fashion until I'm 4 or > 5 levels higher up the call-stack. Often, the higher-level function will > then aggregate several exceptions from lower levels in the stack and make a > "retry/error recovery/continue regardless/inform the user" decision. > Declaring exceptions on the intermediate levels just clutters up my code > base, and offers too much potential for error with nothing to show in > return. > > 2010/9/21 Cédric Beust ♔ <[email protected]> > > > > > > > > > On Tue, Sep 21, 2010 at 2:26 PM, Casper Bang <[email protected]>wrote: > > >> > Checked exceptions allow you to avoid crashing in situations where you > >> > should not be crashing. That's why they are useful. > > >> Sure, that's all fine in theory - but in practice nobody get this > >> boundary right when doing API design; that's a historical fact. > > > Agreed. Nobody said it was easy, and the JDK is a good example of how *not* > > to use checked exceptions correctly in many cases. > > > But should we give up on the concept just because it's hard to get right? > > > It's very much like saying "handling all these error return codes is > > difficult so I'll just ignore them all". > > >> And if a bean setup is erroneous in Spring, then how is a checked > >> exception > >> going to help? > > > A bean set up error is probably not recoverable in most cases, so a runtime > > exception is justified in this case. What is not acceptable is Spring's > > blanket refusal to use checked exceptions anywhere. > > >> Do you really want to wrap every layer in each their > >> own exception, or pollute signatures with long exception lists? > > >> Spring produces stacktraces the size of Pluto, not because of > >> unchecked exceptions, but because it lacks post- and pre-conditions - > >> sanity checks for when to give up. > > > I don't think the difference between pre/post-conditions and runtime > > exceptions is significant enough to make a huge difference in this case > > since they are both runtime events. It's a bit like choosing to let your > > application blow up on an NPE or throwing the NPE yourself after testing the > > variable against null. > > > -- > > Cédric > > > -- > > 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]<javaposse%2bunsubscr...@googlegroups > > .com> > > . > > For more options, visit this group at > >http://groups.google.com/group/javaposse?hl=en. > > -- > Kevin Wright > > mail / gtalk / msn : [email protected] > pulse / skype: kev.lee.wright > twitter: @thecoda -- 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.
