Community
Participate
Working Groups
from Stephan Herrmann inside bug 191125 comment 10 Browsing through all implementations and clients of TypeReference.resolveType() (both overloaded versions), it is clear that this method only has two possible returns: null or a valid TypeBinding. For one implementation this policy is not easy to validate: + ParameterizedQualifiedTypeReference.internalResolveType() The data flow for the final return is non-trivial. Might be interesting to actually analyze. 3 clients actually use a (unnecessary) check isValidBinding() on the result of resolveType(): + ThrowStatement.resolve() + ASTNode.resolveDeprecatedAnnotations() + CompletionEngine.proposeType() (all classes from ...compiler.ast) Here's my suggestion: isn't this kind of policy (null or valid) worth documenting? IMHO that would facility maintenance and extension. The unnecessary checks don't hurt for the functionality, but they tend to confuse people trying to understand the code (like me): a good monkey will copy this kind of code and sooner or later nobody will remember the original policy. Just my 2c.
Ayushman, please see what you can do. Remember that now we should have missing type bindings.
Although it does seem safe to assume that the current implementations of TypeReference.resolveType() , including ParameterizedQualifiedTypeReference.internalResolveType(), either return null or a valid binding, I was wondering if its actually a could idea to document it in TypeReference.resolveType(). What if in the future we do want to have an implementation that returns a problem binding(or change an existing implementation to do so)? To an implementor, a documented contract saying that either null or valid binding is returned, will be a roadbloack in that case. What I mean is, even if we agree that its a trend being followed by implementors currently, we cant guarantee that it'll always be the case. It wouldve made more sense if such a contract was being followed by all implementors of Expression.resolveType(), but I dont think thats the case here. Anyhow, I have limited experience in the area of API and documentation, and it'll be good to have your opinions as well. :) Also, a clarification re comment 1: ThrowStatement.resolve() checks for isValidBinding() on the result of Expression.resolveType() and not TypeReference.resolveType()
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
