A lot of the APT-related bugs I've been looking into are NPEs in the Java compiler. These can be tricky to investigate because it's not immediately clear (to me at least) what a null value means for a particular field or why the field was null in a given circumstance. It's also hard to distinguish a field which was not present due to - say - a parsing error versus a field which is not present due to a programming error in initialization.
Anyone know any good techniques for debugging these?
CDT seems to be using a pattern which may help here. Instead of using null to indicate a problem (an intentionally-omitted field), they insert a non-null sentinel value containing metadata describing the nature of the problem. So if one of these sentinels shows up in an unexpected place, it offers some insight into the reason for the field being omitted... and it also disambiguates parsing errors (non-null sentinels) from initialization bugs in the parser (null).
I'm not suggesting that this be adopted everywhere (which would be a crazy amount of work), but was more curious about what the JDT community felt about the pattern in general. Would patches which adopt this pattern in known problem cases be useful? Well received?
What about the use of org.eclipse.jdt.annotation.Nullable and Nonnull? Would it be helpful for me to add these annotations in locations (in jdt.core) where I've been able to infer the intended contract?
- Stefan
