View Categories

Can you explain how Dart’s null safety works, and how to handle nullable types?

Parthiban Kannan
Updated on December 6, 2025

1 min read

Dart’s null safety is one of its most important features because it helps prevent one of the most common runtime errors in programming: null reference exceptions (often called “null pointer errors”).

In older versions of Dart, any variable could hold null, and that often led to unpredictable crashes at runtime. With null safety (introduced in Dart 2.12), Dart enforces at compile time that a variable cannot be null unless explicitly declared as nullable.

For example:

📄
filename.dart 
int number = 10; // non-nullable
number = null;   // ❌ Compile-time error

But if I explicitly mark it as nullable using a question mark (?), then null becomes allowed:

📄
filename.js 
int? number = 10;
number = null;   // ✅ Allowed

So the difference is clear — int can never be null, but int? can.

Now, when I deal with nullable variables, Dart forces me to handle them safely before using them. There are several ways to do that:

  1. Null check (!) operator
    If I’m absolutely sure a value isn’t null, I can assert it with !:
📄
filename.dart 
int? age;
age = 25;
int validAge = age!; // tells Dart "I’m sure it’s not null"

But I use this sparingly — because if age is actually null, it throws a runtime error.

Null-aware operator (?.)
This lets me access a member or call a method safely — it returns null instead of throwing an exception if the value is null.

📄
filename.dart 
String? name;
print(name?.length); // prints null safely

Null-coalescing operator (??)
I use this to provide a fallback value if something is null:

📄
filename.dart 
String? username;
String displayName = username ?? 'Guest';

This is especially common in Flutter widgets where some data may be missing.

Null-aware assignment (??=)
This assigns a value only if the variable is currently null:

📄
filename.dart 
int? count;
count ??= 0; // assigns 0 only if count is null

In one of my projects — a Flutter e-commerce app — I faced a real challenge with nullable API responses. The backend sometimes returned null for optional fields like discount or description. Before null safety, this led to runtime crashes when trying to display these fields directly in widgets. After migrating to sound null safety, I made the model fields nullable:

📄
filename.dart 
class Product {
  final String name;
  final double? discount;
  Product({required this.name, this.discount});
}

And while displaying, I safely handled it:

📄
filename.dart 
Text('Discount: ${product.discount ?? 0}%')

This eliminated the crashes entirely and made the code self-documented — I can instantly see which values might be null.

A limitation I initially encountered during migration was the complexity of legacy code — pre-null-safety packages or models without type annotations needed a lot of refactoring. Dart’s migration tool helped, but manual cleanup was still needed.

There’s also the concept of late variables, which are non-nullable but initialized later. I use them when I can’t initialize a variable immediately but will do so before use:

📄
filename.dart 
late String token;

void init() {
  token = 'abc123';
}

void main() {
  init();
  print(token); // safe, token is initialized before use
}

However, I need to be cautious — accessing a late variable before it’s assigned throws a runtime error.

As an alternative for safer handling in asynchronous or optional data scenarios, I sometimes use the maybeWhen or fold pattern from functional libraries like dartz — they make null-safe handling more declarative.

So in summary — Dart’s null safety:

  • Enforces non-nullable types at compile time.
  • Uses ?, !, and null-aware operators to handle nullable values.
  • Prevents null-related crashes and improves code clarity.
  • Encourages defensive and predictable programming.

Scroll to Top