Describe Dart's null-aware ?. and null assertion ! operators

What's really being asked

This question probes whether you understand the mechanics of Dart sound null safety, specifically the difference between safely handling a potential null via short-circuiting and forcibly overriding the type system. A senior candidate should demonstrate that ?. is a defensive tool for nullable chains and ! is an escape hatch that shifts safety guarantees from compile time to the developer's judgment.

The full answer

First, define the null-aware operator ?. as an access modifier that evaluates to null immediately if the receiver is null, otherwise dereferences the member. Second, define the null assertion operator ! as a postfix cast that converts a nullable expression to its non-nullable base type, throwing a runtime exception if the value is actually null. Third, give a correct ?. scenario such as reading a property on an optional model object where a null result is acceptable and should propagate. Fourth, give a correct ! scenario such as consuming data from an untyped source like parsed JSON where you have external knowledge the value is present and you want to assign it to a non-nullable variable.

The mistakes people make

A major red flag is conflating ?. with ??; the former propagates null through a chain while the latter supplies a default value. Another mistake is sprinkling ! everywhere as a quick fix for compile errors rather than fixing underlying nullability design. Candidates also err by claiming ! is safe because they personally checked the value, without acknowledging that the compiler cannot verify this and that runtime crashes will occur if the assumption ever breaks. Using ?. in a context that demands a non-nullable result without a fallback is also incorrect.

What usually comes next

The interviewer may ask how Dart's flow analysis and type promotion reduce the need for the ! operator. They might ask you to compare ?? and ?. in a chained expression. They could probe how you would remove unnecessary ! operators from a legacy codebase migrating to null safety. A senior interviewer might also ask about the performance or codegen implications of these operators, or how they interact with late variables.

A concrete example

For the null-aware operator, consider a variable declared as String? maybeName that may hold a name. To safely get its length, you write int? maybeLength = maybeName?.length. If maybeName is null, the expression stops and maybeLength is assigned null; otherwise it receives the string length. For the null assertion operator, imagine a JSON map parsed as Map<String, dynamic?> where a specific key is guaranteed by your backend contract to hold a non-null string. You write String title = json['title']!. This tells the compiler to treat the result as non-nullable String, and if the guarantee is violated the program throws a runtime error, which is appropriate when a null would indicate a contract breach rather than a normal edge case.