I would add a rule, but be conservative about what triggers an error. For instance, we can definitely tell the type of a field. So we know the types of some variables as long as they aren't shadowed. So I would add the rule to the feature list... but wait on implementation.
I have, in my head, a strategy for determining the type of a reference. So if you have 'varName' you can get the type. However, I have not had time to code this. There are a few rules in the backlog that rely on types to perform work, and there are others that would benefit. Maybe in March I can do this work.
So, I would add the rule to the backlog. It's a good idea.
--
Hamlet D'Arcy
ham...@ca...
----- Original Message -----
> We added a rule to ensure that the Object.wait () method is only
> called within a while loop ( WaitOutsideOfWhileLoop ).
>
>
>
> The java.util.concurrent.locks.Condition has a similar “requirement”
> about its await () methods (see the class javadoc).
>
>
>
> If you see a call to wait (), there is no ambiguity about it being the
> wrong wait () method, since it is defined on Object . But the await ()
> methods could catch unintended method invocations (false positives) on
> objects other than Locks .
>
>
>
> So. is it still worth adding a rule for that? I am tempted to think
> so.
>
>
>
> Chris
|
