Sound null safety: nullable types and operators

In Dart a value whose type is String can never be null; only String? admits it. That one rule, enforced by the compiler, is sound null safety, and it turns a whole class of run-time crashes into errors you see before the program runs. The cost is a handful of operators for the places where a value genuinely might be absent.

You will see what non-nullable means and since when Dart enforces it, read the error a ! throws and three safer ways to write it, use the null-aware operators, and build a query whose unset filters simply disappear with Dart 3.8 null-aware elements.

Non-nullable by default

A type is non-nullable unless you add ?. String name must always hold a string; String? note may hold a string or null. This is sound null safetysound null safety: Dart's guarantee that a value whose type is not nullable is never null, checked by the compiler and still true while the program runs. A type allows null only when it says so, as String? does. More in “What Dart is and where it runs”, and “sound” is the strong word: the understanding-null-safety page explains that a value whose static type is non-nullable can never be null at run time, which also lets the compiler drop null checks it knows can never fire. Dart has enforced it since Dart 3, which arrived in 2023 and dropped the language versions before 2.12. The history is short but worth seeing:

Because the guarantee is sound rather than best-effort, you can trust a non-nullable type the way you trust an int to be a number: the type system has already ruled out the absent case.

What you give up is the freedom to leave a value unset by accident; what you gain is that the compiler, not a run-time crash, tells you where a value might be missing. A field that can legitimately be absent is declared nullable, such as String? middleName, and every reader then has to handle the null before using it. A field that must always be present stays non-nullable, and the compiler refuses any path that could leave it null. This turns “could this be null here?” from a question you carry in your head into one the analyzer answers, and it is why reading a ? in a signature is useful information rather than noise.

The null-assertion operator can throw

The ! operator takes a nullable value and asserts it is not null, giving back the non-nullable type. When the value is null, it throws. bang.dart reads a key that is not in the map and asserts it:

// The ! operator asserts that a value is not null. When it is, the program
// throws at run time.
void main() {
  final prices = {'tea': 10};
  final coffee = prices['coffee']!;
  print(coffee);
}

Unhandled exception:
Null check operator used on a null value
#0      main (bang.dart:5:34)
#1      _delayEntrypointInvocation.<anonymous closure> (dart:isolate-patch/isolate_patch.dart:313:19)
#2      _RawReceivePort._handleMessage (dart:isolate-patch/isolate_patch.dart:192:12)

It threw Null check operator used on a null value and ended with status 255. Each ! is a promise the compiler cannot check, so outside tests it is a code smell: it says “I know better than the type system”, and a wrong guess crashes. safe.dart replaces it three ways:

// Three safe ways to read a possibly-missing value instead of the ! operator.
void main() {
  final prices = {'tea': 10};

  // 1. ?? supplies a fallback when the lookup is null.
  final coffee = prices['coffee'] ?? 0;
  print('coffee: $coffee');

  // 2. An if that checks for null promotes the variable to a non-null type.
  final tea = prices['tea'];
  if (tea != null) {
    print('tea: ${tea + 5}');
  }

  // 3. An if-case pattern binds only when the value is not null.
  if (prices['tea'] case final t?) {
    print('tea again: $t');
  }
}

coffee: 0
tea: 15
tea again: 10

It printed coffee: 0, tea: 15 and tea again: 10. The ?? operator supplied 0 when the lookup was null; assigning the lookup to tea and testing if (tea != null) promoted tea to a plain int inside the block; and the if-case prices['tea'] case final t? bound t only because the value was not null. Step through the contrast:

Null-aware operators

For the places where null is expected, Dart has a family of null-aware operatorsnull-aware operator: An operator that works on a value that may be null: ?? and ??= supply a fallback, and ?. and ?.. skip the member access or the cascade when the receiver is null. More in “Operators, cascades and equality in Dart” that do nothing, or supply a value, when the receiver is null. They save the nested if checks that clutter code in languages without them. This table lists the ones you reach for most:

The map lookup in safe.dart returned a nullable int, which is exactly where ?? fits; m['k'] ?? fallback is the everyday replacement for m['k']!. Reach for containsKey or an if-case only when null is itself a valid stored value and you must tell “missing” from “present and null” apart.

Null-aware elements build collections

Dart 3.8 extended null-awareness into collection literals. A ?expr element is included only when it is not null, so a list or map built from optional parts drops the missing ones without an if for each. searchparams.dart builds a query this way:

// Null-aware elements (Dart 3.8): ?expr in a collection drops the element when
// it is null, so unset filters simply disappear.
void main() {
  String? coupon;
  const order = 'order-42';
  const gift = 'gift';
  final items = [order, ?coupon, gift];
  print(items);

  String? city;
  const q = 'chai';
  final params = {
    'q': q,
    'city': ?city,
  };
  print(params);
}

[order-42, gift]
{q: chai}

The list [order, ?coupon, gift] printed [order-42, gift]: coupon was null, so ?coupon contributed nothing. The map wrote 'city': ?city, and because city was null the whole city entry vanished, leaving {q: chai}. This is how you turn a set of optional filters into a query with no empty keys: each optional value is a null-aware element, and only the ones that are set appear.

Never, and the error that keeps nulls out

The rule has teeth at compile time. assign_error.dart tries to put a String? into a String:

// A nullable value cannot be assigned to a non-nullable variable; the compiler
// rejects it.
String shout(String? maybe) {
  String sure = maybe;
  return sure.toUpperCase();
}

void main() => print(shout('asha'));

assign_error.dart:4:17: Error: A value of type 'String?' can't be assigned to a variable of type 'String'.
  String sure = maybe;
                ^

The compiler refused it with “A value of type ‘String?’ can’t be assigned to a variable of type ‘String’” and status 254: you must handle the null first. At the other end sits Never, the type of an expression that never completes normally, such as a function that always throws. never.dart uses one:

// A function that always throws returns Never. Flow analysis knows the code
// after a Never call is unreachable, so n is a non-null int below the if.
Never fail(String message) => throw StateError(message);

int parsePort(String s) {
  final n = int.tryParse(s);
  if (n == null) fail('not a number: $s');
  return n;
}

void main() {
  print(parsePort('8080'));
  try {
    parsePort('oops');
  } on StateError catch (e) {
    print('caught: ${e.message}');
  }
}

8080
caught: not a number: oops

It printed 8080, then caught: not a number: oops. Because fail returns Never, the compiler knows the code after if (n == null) fail(...) runs only when n is not null, so n is promoted to a plain int at return n, with no !. Never is how a throw-helper keeps flow analysis happy, a thread type promotion, late and definite assignment picks up in full.

Practise: remove every !

Take a function that over-uses ! and make it safe.

1. Start from a small order-summary function that reads several nullable fields with !, such as order.coupon! and order.note!, and currently crashes when any is missing.
2. Replace each !: use ?? for a fallback, promotion with an if where the value is used several times, and a null-aware element when building the summary list.
3. Run it with every field set, then with each field null in turn, and confirm it never throws.
4. As a check, make sure dart analyze reports no use of ! left in the function.

When it survives every null, the self-check revisits each section:

Interview questions

Warm-up (fresher): What does the ! operator do, and why is it called a code smell?

The ! operator takes a nullable value and asserts to the compiler that it is not null, giving back the non-nullable type so you can use it. It checks nothing itself: if the value is null at run time, it throws Null check operator used on a null value, as bang.dart did. It is called a code smell because each ! is a promise the compiler cannot verify, so it moves a guarantee from compile time, where null safety usually catches mistakes, back to run time, where a wrong guess becomes a crash. It is fine in a test, where throwing is the point, or right after a check that the analyzer cannot follow. Everywhere else, prefer ?? for a fallback, an if that promotes the value, or an if-case pattern, so the null is handled rather than asserted away.

The bank adds two questions that carry null safety into real cleanup and design work:

Key takeaways

• Types are non-nullable by default; only a ? type such as String? admits null, and Dart has enforced this sound guarantee since Dart 3.
• “Sound” means a non-nullable value can never be null at run time, so the compiler can drop checks and you can trust the type.
• ! asserts non-null and throws when wrong (Null check operator used on a null value); replace it with ??, promotion or an if-case, and keep it for tests.
• The null-aware operators ?., ?[], ??, ??=, ...? and ?.. act only when the receiver is non-null, and Dart 3.8 null-aware elements (?expr) drop null entries from a collection.
• Assigning String? to String is a compile error, and Never, the type of a throw-helper, lets flow analysis promote a value after the helper is called.