I can use that trick. However I'm surprised that the check appears to be so
simplistic.
For example, the following code triggers the check on
getDescription().contains(), since getDescription returns a Nullable
string. However even a simplistic analysis should realize that
getDescription() was checked for null first! I have a dozen or so cases
like this, and I question how useful such a simplistic check it will be.
if (statusCode.equals(Code.INVALID_ARGUMENT)
&& statusCode.toStatus().getDescription() != null
&& statusCode.toStatus().getDescription().contains("finalized")) {
return false;
}
On Mon, Jan 11, 2021 at 8:32 PM Boyuan Zhang <boyu...@google.com> wrote:
> Yeah it seems like the checker is enabled:
> https://issues.apache.org/jira/browse/BEAM-10402. I used
> @SuppressWarnings({"nullness" )}) to suppress the error when I think it's
> not really a concern.
>
> On Mon, Jan 11, 2021 at 8:28 PM Reuven Lax <re...@google.com> wrote:
>
>> Has extra Nullable checking been enabled in the Beam project? I have a PR
>> that was on hold for several months, and I'm struggling now with compile
>> failing to complaints about assigning something that is nullable to
>> something that is not nullable. Even when the immediate control flow makes
>> it absolutely impossible for the variable to be null.
>>
>> Has something changed here?
>>
>> Reuven
>>
>
