Failure Policies

Each operation family has its own config-wide FailurePolicy, independent of the others and defaulting to FALLBACK. Declare them on @Config so every holder of that config follows the same rules:

@Config(
    name = "mymod",
    readFailurePolicy = FailurePolicy.FALLBACK,   // corrupt/invalid file → back it up, restore defaults
    writeFailurePolicy = FailurePolicy.STRICT,    // save failure → throw LiteConfigException
    updateFailurePolicy = FailurePolicy.FALLBACK  // invalid edit → discard, keep current state
)
public final class MyModConfig {
}

Policy	On failure
FALLBACK	Logs and degrades gracefully
STRICT	Throws LiteConfigException

Recoverable failures and configuration errors

FALLBACK handles anticipated runtime failures such as a corrupt file or a rejected value. Configuration and API errors still propagate regardless of policy: examples include a null mutator, an invalid config model, or a validator that throws unexpectedly. This keeps declaration problems visible during development while allowing deployed configs to recover from editable data.

Every LiteConfigException carries a ConfigError code. Branch on the code rather than on message text:

try {
    holder.load();
} catch (LiteConfigException ex) {
    if (ex.error() == ConfigError.IO_LOAD_FAILURE) {
        // file is gone or unreadable
    }
}

Read fallback behavior: when FALLBACK handles a corrupt or invalid file, the bad file is renamed to <filename>.corrupt-<timestamp> and defaults become the published state. During create(), those defaults are immediately written in its place. A later load() keeps them in memory until the next save. The player can recover the original values from the backup.