{"id":62,"date":"2026-09-11T11:00:00","date_gmt":"2026-09-11T09:00:00","guid":{"rendered":"https:\/\/grindloop.io\/blog\/?p=62"},"modified":"2026-09-27T00:08:28","modified_gmt":"2026-09-26T22:08:28","slug":"compose-null-check-crash","status":"publish","type":"post","link":"https:\/\/grindloop.ai\/blog\/compose-null-check-crash\/","title":{"rendered":"The Null Check That Didn’t Save You"},"content":{"rendered":"

A payment screen checks a nullable Compose state for null, then force-unwraps it on the next line. Under normal use it works. Under rapid interaction, a crash report shows a NullPointerException on the !!<\/code>. How can a value that was just checked be null?<\/p><\/blockquote>\n\n\n

var bankMismatchData by remember { mutableStateOf<MismatchData?>(null) }\n\nif (showBankMismatchSheet && bankMismatchData != null) {\n    val mismatchData = bankMismatchData!!\n    BankMismatchSheet(mismatchData)\n}<\/pre>\n\n\n
This Compose null check crash comes from reading the same mutable state twice. bankMismatchData<\/code> is a local delegated property. Every read goes through the delegate’s getter. The getter reads the snapshot state. The null check is one read. The !!<\/code> is a second read. Kotlin knows the two reads might differ. That’s why it refuses to smart-cast here, so you end up writing !!<\/code>. Within one composition pass, both reads usually see the same value. But when a read happens inside a lambda that runs later, it can see a newer value. Sheet content and callbacks are common examples of such lambdas. If another part of the screen has set the state to null by then, the !!<\/code> throws. The fix is to read the state once into a local val<\/code>. Then check and use that local. The compiler can smart-cast it. Nothing can change it between the check and the use.<\/p>\n\n
A Compose null check crash from a real app<\/h2>\n\n
This pattern appears in a May 2026 bug report on Mifos Pay<\/a>, an open-source wallet app. The report covers FastMpayScreen<\/code>. That screen handles QR-code payments across banks. Two nullable mutable states, bankMismatchData<\/code> and pendingAmountConfirmation<\/code>, were each checked for null and then force-unwrapped. The reporter describes a NullPointerException after scanning a cross-bank QR code and interacting rapidly while the sheet renders.<\/p>\n\n
A contributor posted a fix from a fork. It reads each state into a local val<\/code> before the null check. It also removes every !!<\/code> from the file. When this was written, the upstream issue was still open.<\/p>\n\n
Why Kotlin won’t smart-cast this state<\/h2>\n\n
Kotlin’s docs on smart cast prerequisites<\/a> spell out the rule. Smart casts need a guarantee. The compiler must know the variable won’t change between the check and its use. Local val<\/code>s always qualify, except local delegated properties. var<\/code> properties never qualify.<\/p>\n\n
var x by remember { mutableStateOf(...) }<\/code> is a local delegated property. So the compiler won’t smart-cast it after a null check. That’s why the !!<\/code> gets written in the first place. The compiler is telling you the two reads aren’t guaranteed to match. The !!<\/code> gets past that compile error without fixing the cause.<\/p>\n\n
The fix: read once, then branch<\/h2>\n\n\n
\/\/ Unsafe: two reads of a delegated state property\nif (bankMismatchData != null) {\n    val mismatchData = bankMismatchData!!\n    BankMismatchSheet(mismatchData)\n}\n\n\/\/ Safe: one read, captured in a local val the compiler can smart-cast\nval mismatchData = bankMismatchData\nif (mismatchData != null) {\n    BankMismatchSheet(mismatchData)\n}<\/pre>\n\n\n
The second version reads the state once. The local val<\/code> can’t change, so the compiler smart-casts it to non-null inside the if<\/code>. Any lambda inside BankMismatchSheet<\/code> now captures the checked value, not the live state. This isn’t a Compose trick. It’s the same discipline Kotlin asks for with any mutable property.<\/p>\n\n
What to look for in code review<\/h2>\n\n
Watch for remember { mutableStateOf(...) }<\/code> with a nullable type, followed by a null check and a !!<\/code>. The buggy version compiles cleanly and looks guarded. It may only fail under timing you rarely hit in manual testing. The same applies to var<\/code> properties in ViewModels and other classes.<\/p>\n\n
How to answer this in an interview<\/h2>\n\n
    \n
  1. Say that the check and the !!<\/code> are two separate reads of mutable state.<\/li>\n
  2. Explain why the compiler refused to smart-cast. The state is a local delegated property, so the compiler can’t guarantee both reads match.<\/li>\n
  3. Name when the reads can differ. That happens when the second read runs later, inside a lambda such as sheet content or a callback.<\/li>\n
  4. Give the fix as a rule. Read mutable state into a local val<\/code> once, then branch on the local.<\/li>\n<\/ol>\n\n
    Common wrong answers:<\/strong><\/p>\n