Null Safety #

The null reference error (Null Pointer Exception or Null Reference Error) — famously called by its creator, Tony Hoare, the “billion-dollar mistake” — is one of the most common causes of software app crashes worldwide. For decades, developers had to write thousands of lines of defensive validation code manually to check whether data was empty before accessing its properties. Dart solves this problem fundamentally through Sound Null Safety. This system guarantees that a variable will never be null unless you explicitly allow it, and this safety guarantee holds absolutely until the app runs on the user’s device (runtime).

The Problem Null Safety Solves #

Before the null safety feature was introduced in Dart 2.12, the Dart compiler had no ability to distinguish whether a variable was safe from null values. This condition often let fatal bugs slip through to users without any warning during the compilation process:

// ANTI-PATTERN: Old Dart code (before Null Safety) that is prone to crashing
String fetchUserName() {
  // Can return null if the connection has issues or data is empty
  return null; 
}

void printUserLength() {
  String name = fetchUserName(); 
  // IF name is null at runtime, this line will CRASH instantly!
  // Error: NoSuchMethodError: The getter 'length' was called on null.
  print(name.length); 
}

The bug above is very dangerous because it slips past static compiler analysis while you write code, and only explodes into a crash after the app is installed and used by customers.

With Sound Null Safety, this kind of error is caught immediately by the compiler while you write code (compile-time), cutting the bug chain before it can be distributed:

// CORRECT: Modern Dart code with Sound Null Safety
String? fetchUserName() {
  // You must use a nullable type (String?) to return null
  return null; 
}

void printUserLength() {
  // COMPILE-TIME ERROR: The non-nullable 'name' variable cannot accept a nullable value
  // String name = fetchUserName(); 
  
  // The correct solution:
  String? name = fetchUserName();
  if (name != null) {
    print(name.length); // Safe — the compiler guarantees name is not null inside this block
  }
}

Non-Nullable by Default #

The main fundamental principle of Dart’s type system is Non-Nullable by Default (NNBD). This means, by default, all data types in Dart — both primitive types like int, double, String, and bool, and your custom class object types — are considered sterile and must not hold null values.

// NON-NULLABLE (Default) — Must have a concrete value, cannot be null
String siteName = 'flutter.unisbadri.com';
int activeUsers = 1500;
bool isServerRunning = true;

// The following errors will trigger immediate compilation errors:
// siteName = null;        // ERROR
// activeUsers = null;     // ERROR
// isServerRunning = null; // ERROR

// NULLABLE — Add the question mark operator (?) to allow null
String? pendingTask = null;    // Valid
int? userAge;                  // Valid, automatically defaults to null

The Type Hierarchy Change #

Before the null safety era, the Null type acted as a universal subtype of all data types. This meant a null value could freely sneak into variables of any data type. After null safety was enabled, Dart’s type system hierarchy underwent a revolutionary change:

flowchart TD
    subgraph BeforeNullSafety["Type Hierarchy Before Null Safety (Dart < 2.12)"]
        direction TB
        ObjB["Object (Top Type)"]
        StrB["String"]
        IntB["int"]
        NullB["Null (Subtype of all types)"]
        
        ObjB --> StrB
        ObjB --> IntB
        StrB --> NullB
        IntB --> NullB
    end
    subgraph AfterNullSafety["Type Hierarchy After Null Safety (Dart >= 2.12)"]
        direction TB
        ObjNullable["Object? (Top Nullable Type)"]
        ObjNonNullable["Object (Top Non-Nullable Type)"]
        StrA["String"]
        IntA["int"]
        NullA["Null (Only compatible with nullable types)"]
        
        ObjNullable --> ObjNonNullable
        ObjNullable --> NullA
        ObjNonNullable --> StrA
        ObjNonNullable --> IntA
    end
    
    style BeforeNullSafety stroke:#f44336,stroke-width:2px
    style AfterNullSafety stroke:#4caf50,stroke-width:2px

In the modern hierarchy, the Null type has been isolated from the non-nullable type group. The Null type is now only compatible under the Object? branch (the top nullable type).

Additionally, Dart introduced a new type called Never at the very bottom of the hierarchy (bottom type). The Never type states that an expression will never produce any value, for example a function designed to always throw an error (exception) or run an infinite loop.

Null-Aware Operators #

To make working with nullable types easier without writing long, repetitive if-else check blocks, Dart provides a series of special operators called Null-Aware Operators:

1. The ?. Operator (Null-Aware Access) #

This operator is used to safely access a property or call a function from a nullable object. If the object turns out to be null at execution, the system won’t crash — it just returns null.

String? authorName = getAuthorName();

// The long traditional defensive approach:
int? traditionalNameLength;
if (authorName != null) {
  traditionalNameLength = authorName.length;
}

// CORRECT: Using concise null-aware access
int? modernNameLength = authorName?.length; // Returns null if authorName is null

2. The ?? Operator (Null Coalescing) #

This operator provides an alternative (fallback) value if the expression on the left side is null.

String? apiResponse = fetchResponseFromServer();

// If apiResponse is null, the output variable is automatically filled by the string on the right
String displayMessage = apiResponse ?? 'Connection failed, please try again.';

3. The ??= Operator (Null-Aware Assignment) #

This operator assigns a new value to a variable only if the variable is currently null.

String? temporaryCache;

temporaryCache ??= 'Initial Value'; // temporaryCache is filled with 'Initial Value' because it was null
temporaryCache ??= 'New Value'; // Ignored, because temporaryCache already has a value
print(temporaryCache); // Output: 'Initial Value'

4. The ! Operator (Null Assertion / Bang Operator) #

This operator acts as a force. You instruct the Dart compiler to treat a nullable variable as if it’s definitely non-nullable.

String? databaseToken = getActiveToken();

// Use this operator only if you're 100% CERTAIN the data is not null
String activeToken = databaseToken!;

[!WARNING] Avoid Excessive Bang Operator (!) Usage Forcing the ! operator bypasses compile-time protection. If the variable turns out to be null at runtime, the app will immediately throw a runtime crash: Null check operator used on a null value. Use this operator as little as possible and prefer the ?? operator or type promotion techniques.

5. The ?[] Operator (Null-Aware Index Access) #

This operator safely reads element values inside a nullable collection (List or Map) by index or key.

List<String>? categories = fetchCategories();

// Safely getting the item at index 0, returns null if the list is null
String? firstCategory = categories?[0];

6. The ?.. Operator (Null-Aware Cascade) #

This operator safely runs a chain of sequential method calls (cascade) on an object that might be null.

Path? drawPath = getPath();

// All the instructions in the chain below only execute if drawPath is not null
drawPath
  ?..moveTo(0, 0)
  ..lineTo(100, 150)
  ..lineTo(200, 300)
  ..close();

Type Promotion #

One of the smartest features in Dart’s null safety implementation is Type Promotion. The Dart compiler has static control flow analysis capabilities to automatically change (promote) a nullable type to non-nullable if you’ve done a null validation check beforehand.

flowchart TD
    VarNullable["Nullable Variable (String? x)"] --> NullCheck{"Is There a Null Check?\n(if x != null / early return)"}
    NullCheck -->|"Yes (Within Block Scope)"| Promote["Promote to Non-Nullable (String x)"]
    NullCheck -->|"No"| Retain["Keep Nullable (String? x)"]
    
    Promote -->|"Direct Property Access"| Direct["x.length (Safe & Valid)"]
    Retain -->|"Direct Property Access"| CompileError["x.length (Compile Error!)"]
    
    style NullCheck stroke:#0288d1,stroke-width:2px

Notice how type promotion simplifies your code:

void processProfile(String? userBio) {
  // Here userBio is of type String? (nullable)
  // print(userBio.length); // COMPILE-TIME ERROR: The 'length' property cannot be accessed directly

  if (userBio != null) {
    // CORRECT: Inside this block, userBio is automatically promoted to String (non-nullable)
    print(userBio.length); // Syntactically valid, no need for ?. or ! operators
  }
}

1. Promotion Through Early Return (Guard Clause) #

You can use the early return pattern to clean null potential from code branches since the first line of the function:

String formatMessage(String? rawInput) {
  // If the data is null, immediately stop the function
  if (rawInput == null) return 'Empty Input';

  // After passing the line above, rawInput is automatically promoted to non-nullable String
  return rawInput.trim().toUpperCase(); 
}

2. Promotion on Private Final Fields #

Starting from Dart 3.2, type promotion was extended to detect and promote private final field properties:

class ConfigurationManager {
  final String? _localApiKey; // Private final field

  ConfigurationManager(this._localApiKey);

  void authenticate() {
    if (_localApiKey != null) {
      // Dart 3.2+: _localApiKey is automatically promoted to non-nullable String
      print('Authenticating using a key with length: ${_localApiKey.length}');
    }
  }
}

[!NOTE] Why Doesn’t Type Promotion Work on Public or Non-Final Fields? The Dart compiler is very cautious to guarantee type safety. If a property is public or non-final (its value can change at any time), there’s a risk that another thread or external code changes the property to null right after the if (_apiKey != null) check but before the print(_apiKey.length) line executes. Only properties guaranteed not to change (i.e., private and final/immutable) are safe for automatic promotion.

The late Keyword #

The late keyword declares a non-nullable variable whose value can’t be determined during initial compilation, but you give the compiler a guarantee that the value will definitely be initialized before first access at runtime.

There are two main scenarios for using late in Dart:

1. Deferred Non-Nullable Initialization (Late Initialization) #

This scenario is very common when the variable initialization process requires an object from outside the class that’s only available at runtime, like during async setup:

class UserProfileFetcher {
  // You guarantee to the compiler that _cachedDatabase will definitely be filled before access
  late final LocalDatabase _cachedDatabase;

  Future<void> initializeDatabase() async {
    // Initialization only happens asynchronously here
    _cachedDatabase = await LocalDatabase.connect('profile.db');
  }

  Future<User> fetchProfile(String userId) async {
    // You can directly call _cachedDatabase without null check protection
    return await _cachedDatabase.queryUser(userId);
  }
}

[!WARNING] The Danger of LateInitializationError at Runtime If you try to read a variable with the late modifier before it’s actually initialized in memory, Dart will throw a runtime error: LateInitializationError: Field '_cachedDatabase' has not been initialized. Use late only if you can guarantee the initialization execution order runs correctly.

2. Lazy Evaluation (Lazy Initialization) #

When you combine late with a direct initialization declaration, the variable transforms into a Lazy Variable. The variable’s value won’t be computed when the class object is created, but only processed when the variable is first read in code:

class ComplexReportGenerator {
  // The large file loading operation below won't be triggered when the object is created
  late final List<String> _heavyConfigLines = _loadLargeConfigFile();

  List<String> _loadLargeConfigFile() {
    print('Starting heavy config file loading...');
    return File('huge_configuration_data.txt').readAsLinesSync();
  }

  void executeQuickTask() {
    print('Quick task done.'); // If this function is called, _loadLargeConfigFile() never runs
  }

  void executeAnalysis() {
    // File loading is automatically triggered at this line because _heavyConfigLines is read
    print('Config count: ${_heavyConfigLines.length}'); 
  }
}

Null Safety and Performance #

Sound Null Safety doesn’t just give you convenience when writing code — it also has a very significant performance acceleration impact on production release binaries.

Observe the machine code execution flow differences below:

APP WITHOUT NULL SAFETY:
  C++ Instruction: Read memory address of variable 'X'
  C++ Instruction: Check whether memory address 'X' points to 0x0 (implicit null check)
  C++ Instruction: If yes, throw NullPointerException to runtime
  C++ Instruction: If not, read 'X' data property
  --> Hundreds of implicit null checks fill the app's binary machine code.

APP WITH SOUND NULL SAFETY:
  C++ Instruction: Read memory address of variable 'X' (Compiler guarantees the address is definitely valid)
  C++ Instruction: Directly read 'X' data property (Without checking 0x0)
  --> Much cleaner machine code, smaller binary size, increased CPU execution performance.

Because Dart’s type system is Sound, the AOT (Ahead-Of-Time) compiler can trust type information 100% during the build phase. The compiler safely eliminates (tree shakes) all implicit null check instructions from the final machine binary. The result is a smaller app file size, more efficient RAM usage, and a runtime ecosystem running at full speed.

Common Null Safety Patterns in Flutter #

Let’s study best-practice null safety implementations in Flutter interface components:

1. Designing Widgets with Optional Properties #

When creating widgets, you often have optional properties (e.g., a user profile card whose photo may be empty if the user hasn’t uploaded one):

class UserProfileCard extends StatelessWidget {
  final String fullName;
  final String? profilePhotoUrl; // Nullable, because the profile photo is optional
  final String? customStatus;    // Nullable

  const UserProfileCard({
    super.key,
    required this.fullName,      // Required, non-nullable
    this.profilePhotoUrl,        // Optional, may be null
    this.customStatus,           // Optional, may be null
  });

  @override
  Widget build(BuildContext context) {
    return Card(
      child: Column(
        children: [
          // CORRECT: Using Dart 3 pattern matching to safely render nullable visuals
          switch (profilePhotoUrl) {
            final url? => Image.network(url), // Promoted to non-nullable String
            _ => const Icon(Icons.account_circle, size: 80),
          },
          
          Text(fullName),
          
          // Using conditional rendering if customStatus is not null
          if (customStatus case final status?)
            Text(status, style: const TextStyle(fontStyle: FontStyle.italic)),
        ],
      ),
    );
  }
}

2. Null Safety Integration with FutureBuilder #

When loading data from the internet using an API, you often have to handle three state conditions: loading, success with data, or failure resulting in null:

class ProductDetailsView extends StatelessWidget {
  final Future<Product?> productFuture;

  const ProductDetailsView({super.key, required this.productFuture});

  @override
  Widget build(BuildContext context) {
    return FutureBuilder<Product?>(
      future: productFuture,
      builder: (context, snapshot) {
        if (snapshot.connectionState == ConnectionState.waiting) {
          return const CircularProgressIndicator();
        }
        
        // Checking whether an error occurred or the returned data is null
        if (snapshot.hasError || !snapshot.hasData || snapshot.data == null) {
          return const Text('Product not found or connection lost.');
        }

        // At this line, snapshot.data is safely promoted to non-nullable Product
        final product = snapshot.data!; 
        return Column(
          children: [
            Text(product.name),
            Text('Price: Rp ${product.price}'),
          ],
        );
      },
    );
  }
}

Summary #

  • The Billion-Dollar Mistake — Null Pointer Exceptions are completely solved in Dart through Sound Null Safety by guaranteeing data reference safety.
  • NNBD by Default — All data types in Dart are Non-Nullable by Default. Variables must be marked with the ? operator to accept null values.
  • Null Safety Operators — Provides a series of concise operators like ?. (safe access), ?? (fallback value), ??= (conditional assignment), and ?[] (safe list/map indexing).
  • Automatic Type Promotion — The Dart compiler smartly promotes nullable variables to non-nullable after a null check passes in the code control flow.
  • Private Final Field Support — Starting from Dart 3.2, automatic type promotion can be applied to immutable private property variables.
  • Two Functions of late — Used to declare deferred non-nullable initialization (late init) or postpone heavy computation execution (lazy evaluation).
  • Binary Performance Acceleration — Runtime type correctness guarantees let the AOT compiler discard thousands of implicit null-check instructions to speed up app startup.

← Previous: Overview   Next: Asynchronous Programming →

About | Author | Content Scope | Editorial Policy | Privacy Policy | Disclaimer | Contact