Is there a reason to check if a non-nullable parameter is null?

Question

I'd expect a non-nullable parameter to never ever be null. But I've came across this piece of code in Flutter source. The assertions (and comments) seem redundant (link to the code):

  /// Creates a route that delegates to builder callbacks.
  ///
  /// The [pageBuilder], [transitionsBuilder], [opaque], [barrierDismissible],
  /// [maintainState], and [fullscreenDialog] arguments must not be null.
  PageRouteBuilder({
    super.settings,
    required this.pageBuilder,
    this.transitionsBuilder = _defaultTransitionsBuilder,
    this.transitionDuration = const Duration(milliseconds: 300),
    this.reverseTransitionDuration = const Duration(milliseconds: 300),
    this.opaque = true,
    this.barrierDismissible = false,
    this.barrierColor,
    this.barrierLabel,
    this.maintainState = true,
    super.fullscreenDialog,
  }) : assert(pageBuilder != null),
       assert(transitionsBuilder != null),
       assert(opaque != null),
       assert(barrierDismissible != null),
       assert(maintainState != null),
       assert(fullscreenDialog != null);

I thought maybe if I pass an argument of type dynamic, I might be able to hit the asserts, but nope, the following code triggers a TypeError, not AssertionError:

final x = (() => null)();
PageRouteBuilder(
  pageBuilder: (_, __, ___) => const Placeholder(),
  opaque: x,
),

Backwards compatibility also seems out of question because AFAIK Flutter version is tied to a certain Dart version. So are these asserts (and comments) in Flutter code simply redundant, or is there a reason for them?

The `assert`s are vestigial. In some cases it might be because they were accidentally left in after migrating the code, but usually it was to handle [mixed-mode cases](https://dart.dev/null-safety/unsound-null-safety) during the transition period. Also see https://dart.dev/null-safety/faq#how-should-i-migrate-an-assertx--null-that-now-shows-as-unnecessary — jamesdlin, Jun 20 '22 at 20:15
Michael Horn is right. But i want to add an article about null safety. https://medium.com/flutter-students-club/really-null-safety-in-flutter-dart-56e2a70a3849 — Mehmet Yaz, Jun 20 '22 at 20:17

score 4 · Accepted Answer · answered Jun 20 '22 at 20:15

Those assertions are just a holdover from the pre-null-safety days. They're no longer necessary, but they do no harm either.

Before null safety, named parameters could always be null, since they could be omitted. You could indicate that they were required, by adding @required before a named parameter, but even that would only yield a compiler warning. So if a required named parameter was really required, the only way to enforce that they were passed was to use such assertions, and crash the user's program on improper usage (which is better than undefined behavior).

Is there a reason to check if a non-nullable parameter is null?

1 Answers1