|[cdt-dev] API Design Discussion: Enforcing null Checks with Optional|
In the wake of implementing and reviewing structured bindings  Nate and I had a quick discussion about the API design of public interfaces in CDT. A new interface will be introduced for representing structured binding AST nodes. In this interface we declare two methods that return objects/values that might be missing in the C++ source code and therefore require null checks on the call-side when using the corresponding node:
While the first case could be solved by just adding a further value to the RefQualifier enumeration (RefQualifier.NONE), the latter case requires a null-check (unless we introduce a NullInitializer AST node). So far we seemed to always just mention the need for a null check in the documentation of the interface. Since Java 8 we could alternatively state this need explicitly in the API by returning an Optional<IASTInitializer>. Is there any official guideline for API design regarding this aspect CDT follows?
I currently followed the Optional-approach for the structured bindings patch, but I would like to check back with the other committers before I submit it and make the API design inconsistent.
I’m looking forward to your comments!
Back to the top