On Fri, 10 Sep 2010 Sean Owen <[email protected]> wrote: > As you might see, the number of such warnings has come down from > thousands to hundreds.
Yeah! > 1. One common one is "overrideable method called in constructor". > This is a reasonable point. > B breaks A by subclassing. Making the method or class final solves > it, which is my preferred solution where I do not see any reasonable > case for subclassing. I'd prefer marking the method itself as either final or private - still leaves more freedom to the user who may see reasonable cases for subclassing that the initial developer did not think of. > 2. Another is complaining about methods that throw 7 or more > exceptions. There are a number like this and it strikes me that it > can't really be the best thing. They could be wrapped in a generic > exception, or, in cases where the caller can't reasonably do > anything, try to log and handle the condition internally. Writing such a method, me personally I'd prefer throwing some generic exception* over silently catching the exception - at least in cases where the error condition cannot reasonably be fixed in the method it occurred in. * It should retain enough information to allow for logfile analysis. > 3. Last one I see a lot is the "really long method" warning. I agree > with it but not sure how much it's worth chopping up methods. Good to > think of when refactoring though. +1 Isabel
