Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] API Design Discussion: Enforcing null Checks with Optional
Optional imposes run-time overhead and should be avoided in my opinion. In my current project we are using mandatory @Nullable/@NotNull annotations and it works very well. Eclipse has exceptionally good support for type-based nullability annotations, much better that IntelliJ that I'm currently using.

Sergey

On Fri, Jul 26, 2019 at 2:11 AM Corbat Thomas <thomas.corbat@xxxxxx> wrote:

Hi everyone

 

In the wake of implementing and reviewing structured bindings [1][2] 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:

  • It  might contain a reference qualifier (& or &&), there is a method for retrieving it (getRefQualifier). This is optional by the standard.
  • While it is not valid by the standard, our parser gracefully accepts the omission of the initializer.

 

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!

 

Thomas

 

 

 

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=522200

[2] https://git.eclipse.org/r/c/126387/

 

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev

Back to the top