[Rule change] `avoid-non-null-assertion`: Maybe ignore `if(some.field != null) some.field!`

[fzyzcjy]

What rule do you want to change?
avoid-non-null-assertion

How will the change be implemented? (New option, new default behavior, etc.)?
will fill out more details if interested

Please provide some example code that this change will affect:

What does the rule currently do for this code?

What will the rule do after it's changed?

Are you willing to submit a pull request to implement this change?

[incendial]

Agree, that looks doable

[roman-petrov]

@incendial - if you decide to make avoid-non-null-assertion more permissive, can you please make it optional? I'm a bit fan of strict restrictions and currently do not see any problems with strict avoid-non-null-assertion on our codebase.

[fzyzcjy]

@roman-petrov

Agree and that sounds not hard to implement.

By the way, I am curious how do you deal with the following cases?

• if(some.field != null) some.field! (especially when that field is a final primitive field)
• SomeInheritedWidget.of(context)!.something (when the inherited widget really should be there, otherwise the programmer is making a big mistake, and we should throw instead of silently fallback)

[roman-petrov]

@incendial

By the way, I am curious how do you deal with the following cases?

• if(some.field != null) some.field! (especially when that field is a final primitive field)
• SomeInheritedWidget.of(context)!.something (when the inherited widget really should be there, otherwise the programmer is making a big mistake, and we should throw instead of silently fallback)

At the moment in these cases our code becomes a bit verbose like

final value = some.field;
if (value != null) {
...
}

and that's ok for us.

A few month ago in "Flutter Dev Podcast" channel I participated in some discussions with Vyacheslav Egorov about such cases and as I understood:

• When we do if(some.field != null) some.field! we do not have 100% protection from NPE, null safety still can be violated in this case.
• Dart language team might decide to implement some language feature that makes code less verbose for such cases, something like

if ((final value = some.field) != null) {
...
}

This discussed language feature also might be related to this topic: Enable promotion for private final fields and fields on non-escaping private classes

[fzyzcjy]

@roman-petrov Thank you for the elaboration!

So I wonder how did you solve the second case, i.e.: SomeInheritedWidget.of(context)!.something (when the inherited widget really should be there, otherwise the programmer is making a big mistake, and we should throw instead of silently fallback)

[roman-petrov]

So I wonder how did you solve the second case, i.e.: SomeInheritedWidget.of(context)!.something (when the inherited widget really should be there, otherwise the programmer is making a big mistake, and we should throw instead of silently fallback)

About the second case: we do not use inherited widgets much. For example, some built-in Flutter inherited widgets return non nullable values (like Theme.of(context)).

But if I had to - I would use the same approach as I described above like

final widget = SomeInheritedWidget.of(context);
if (widget == null) { 
   throw ...
}

I don't think I would use exactly the same code I listed, but the concept will not change - check nullable before doing something. Without exceptions:)

I understand that some people will dislike such approaches, but everybody can have his own opinion about how to make things better :)

[fzyzcjy]

@roman-petrov Thanks for explaining your approach! I will consider about it.