Vladimir Sitnikov created CALCITE-4311: ------------------------------------------
Summary: Add non-nullable experimental accessors side by side with their nullable counterparts Key: CALCITE-4311 URL: https://issues.apache.org/jira/browse/CALCITE-4311 Project: Calcite Issue Type: Sub-task Affects Versions: 1.25.0 Reporter: Vladimir Sitnikov Certain APIs are declared to return nullable values, however, they are often used in "I know this must be non-null" context. For instance: {{Wrapper#unwrap(Class)}}. It happens so that {{.unwrap(Table.class)}} is quite common. For instance: {code:java} final Table leftTable = leftRelOptTable.unwrap(Table.class); final int leftCount = leftRelOptTable.getRowType().getFieldCount(); {code} It would be nice if unwrap could fail with a proper message like "oh, I can't find Table in ...", so the end users would get better error messages, and the code would be way easier to read. For instance: {code:java} // unwrapNonNull can be declared as a default implementation final Table leftTable = leftRelOptTable.unwrapNonNull(Table.class); final int leftCount = leftRelOptTable.getRowType().getFieldCount(); {code} --- Another case is {{org.apache.calcite.sql.SqlSelect#getSelectList}}. The method returns a nullable value, however, it is often used as if it was non-nullable. Initially, I thought of adding static helper methods to utility classes/interfaces, however, now I'm inlined to adding non-nullable getters right to the original classes/interfaces. That would make the code easier to read and write. -- This message was sent by Atlassian Jira (v8.3.4#803005)