Ted: I agree. I forgot about that case. Robin: There is a strange general habit in Java of this situation. Consider Thread. I'm perfectly happy to add the throws clause, but one might wonder why the 'classic' examples all have the problem you cite.
On Sat, Feb 13, 2010 at 4:20 PM, Robin Anil <robin.a...@gmail.com> wrote: > On the topic of code cleanup. > > Current OpenXXYYhashmaps has to throw runtime exception on an IOException in > Hadoop > > This will make that statement clear > > void map(Text key, Text value, final OutputCollector output){ > > forEachPair(function(){ > �...@override > bool apply(key, value){ > try { > do something; > output.collect(key1,value1); > } > catch(IOException e){ > throw new RuntimeException(e); > } > return true; > } > } > > } > > > What to do here? Why not let ObjectProcedure class throw Exception ? > > > > > On Sun, Feb 14, 2010 at 2:37 AM, Robin Anil <robin.a...@gmail.com> wrote: > >> final doesnt necessarily mean mutable right? >> >> >> On Sun, Feb 14, 2010 at 2:35 AM, Benson Margulies >> <bimargul...@gmail.com>wrote: >> >>> I'm not very fond of a plague of finals. Here's why. >>> >>> Consider >>> >>> final int[] x = new int[10]; >>> >>> That doesn't, sadly, prevent >>> >>> x[2] = 1; >>> >>> So, to me, final is too weak to be useful. I put them in code when >>> required due to the rules about anonymous functions capturing locals, >>> but never otherwise. >>> >>> Just my 1cent on this subject. >>> >>> >>> On Sat, Feb 13, 2010 at 3:21 PM, Robin Anil <robin.a...@gmail.com> wrote: >>> > Only done for local fields. And handpicked ones in bayes for local >>> variables >>> > due to openXXYYHashMap.foreach() requiring final objects >>> > >>> > >>> > On Sun, Feb 14, 2010 at 1:47 AM, Ted Dunning <ted.dunn...@gmail.com> >>> wrote: >>> > >>> >> I find final slightly helpful on fields, very helpful on static fields, >>> but >>> >> not very helpful at all on local variables. The issue is scale. With >>> a >>> >> field there are lots of places you can bugger it up. If the scope of a >>> >> local is large enough for similar confusion, you have a different >>> problem >>> >> anyway. >>> >> >>> >> I am generally -1 to too many final declarations on parameters and >>> local >>> >> variables, but I don't go to the trouble of deleting them if I see >>> them. >>> >> >>> >> On Sat, Feb 13, 2010 at 11:03 AM, Sean Owen <sro...@gmail.com> wrote: >>> >> >>> >> > I'm late on this but have a question about the final business. I >>> >> understand >>> >> > the style it is promoting and even like it and used to do it. I >>> stopped >>> >> > because it does get harder to read and its not usual in java code. >>> Any >>> >> > thoughts on that. >>> >> > >>> >> > On Feb 13, 2010 2:55 PM, "Robin Anil" <robin.a...@gmail.com> wrote: >>> >> > >>> >> > I just did a mass code cleanup. >>> >> > >>> >> > Mainly comprising of >>> >> > -Extra blank line removal >>> >> > -Organize Imports across all packages. >>> >> > -Making local variables final >>> >> > >>> >> > No reordering of methods or code style changes are applied. >>> >> > >>> >> > Any objections or any particular class to withhold from committing. >>> >> > >>> >> > Robin >>> >> > >>> >> >>> >> >>> >> >>> >> -- >>> >> Ted Dunning, CTO >>> >> DeepDyve >>> >> >>> > >>> >> >> >