Error Handling

get() and field reads throw DocumentDecodingException when a stored field can't be decoded — never a bare, low-level exception from the serialization layer.

try {
    val current = note.get()
} catch (e: DocumentDecodingException) {
    log.warn("note-1 field '${e.field}' failed to decode", e.cause)
}
Note

In practice this is rare — it only fires if a stored field is genuinely corrupted or was written by an incompatible old version of your app. You don't need a try/ catch around every single get() call; reach for one at a boundary that already handles unexpected failures (a repository layer, a top-level error handler), not around every read in your codebase.

What it wraps, and why

Because a document is decomposed into one MMKV key per field (see Field Decomposition), a single field can go bad — a corrupted byte range, a stale format from an old app version — while every other field in the same document stays perfectly healthy. DocumentDecodingException names the documentKey, the offending field when there is one, and wraps the underlying cause, which might otherwise have surfaced as a bare SerializationException, IllegalStateException, or IllegalArgumentException from the CBOR format. Your code catches one clean library exception type instead of reaching into the serialization layer's own error hierarchy.

A configured field decorator that throws one of those same three exception types from unwrap — a wrong key, corrupted ciphertext, a failed integrity check — is wrapped the same way, indistinguishable from any other decode failure.

What's not an error

A document that was simply never written is not a decoding failure — get() returns null for that case, it never throws just because something is missing. See Read & Write.

A distinct case: update() on a never-written document

update() can also throw DocumentDecodingException the very first time it runs against a document that's never been set() — but the cause there isn't corruption, it's a data class field with no constructor default and no nullability to fall back on. The exception message is identical to a genuine decode failure today, which makes it easy to mistake for one. See Declaring Data Classes for why this happens and how to avoid it.