On Sun, Feb 14, 2010 at 10:10 AM, Sean Owen <sro...@gmail.com> wrote: > Well a third option is a checked exception that is not Exception.
I'm not sure that I see this as very useful for the collections the the following reason. A procedure passed to a collections 'foreach' can do \anything/ and incur any exception. IOException will never extend whatever we define. So, it's a choice between users wrapping their exception in something we define and wrapping it in some unchecked exception that they define. I have this feeling that I'm not typing anything insightful here, and I am a resounding +0 for the this idea. > > I feel we should determine what makes sense API-wise then implement > accordingly. > > Does F have any exceptional termination condition where it can't return? If > no, of course F declares no exception. > > If yes, can the situation occur in a normally functioning bug free program? > If no, use an unchecked exception besides RuntimeException in implementation > code and declare no checked exception. > > If yes, choose a checked exception which accurately reflects the fault - or > make one - and declare it in F. In no circumstance in Exception the right > choice. > > I gave my view on map() elsewhere - no checked exception. > > On Feb 14, 2010 2:42 AM, "Benson Margulies" <bimargul...@gmail.com> wrote: > > I'm getting double vision from the multiple discussion on the 'mass > checkin' thread, so here's a new one. > > So, we have a function F that applies another function to some number > of things. What should it do about exceptions? > > Answer 1: (currently in place) No throws clause at all on the > signature. If such a function needs to throw, it must throw an > unchecked exception. > > Answer 2: F should 'throw Exception' to declare that the applied > function could, in fact, throw any checked exception. > > I checked, and, sadly, there is no option 3. Generics never touch the > throws clause. > > In code I own, I confess (insofar as I have a great deal of respect > for Ted's views) that I've been choosing door #2 when there are a lot > of exception around. This is the only case where I ever write 'throws > Exception'. Nonetheless, when I was housecleaning Colt, I didn't > sprinkle these around, because I had a vague sense that answer #1 is > the predominant approach. > > I read Ted's views as a resounding -1 for switching from 2 to 1, so I > think the code should stay as it is. >