Well a third option is a checked exception that is not Exception. 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.
