Lectures

We break down why file operations on the JVM “break”, why checking exists() does not guarantee success, how the “umbrella” IOException differs from FileNotFoundException, how to structure try/ catch correctly (from specific to general), and what to print for diagnostics (operation, path, and the properties exists/ isFile/ isDirectory) so you do not turn debugging into guesswork.

We cover practical file pre-checks in Kotlin/JVM: how to make sure a path exists, that it is actually a file, and that it is readable before reading ( exists(), isFile, canRead()), and how to prepare the parent directory before writing using parentFile and mkdirs(). Separately: quick path diagnostics and common mistakes (checking only exists(), ignoring the mkdirs() result, the illusion of guarantees from canWrite()).

We break down why, for file operations in Kotlin, you can’t rely only on checks like exists() and why you still need try/ catch around real I/O. We learn to make a “narrow” try around readText()/ writeText(), use try as an expression, choose a function contract ( T?, Boolean, or rethrowing IOException), write useful error messages, order multiple catch blocks correctly, and close resources via use {}.

We break down a practical “atomic write” protocol for saving important data to a file: why a direct call to writeText() during overwrite can leave a “truncated stub” on failure, how to write the new version to a temp file next to the target and then “publish” the result via renameTo(). We will assemble a function atomicWriteText with try/ finally, discuss the trade-offs of deleting the target, and typical mistakes (temp not next to the target, not checking the renameTo result, catching everything, etc.).

We break down why you need a backup on top of atomic write, how to make the simplest .bak copy before replacing a file, why rotating copies should be done “from the end”, and how to assemble a safe save protocol: rotateBackups → atomicWriteText. At the end — a process diagram in mermaid and an analysis of typical mistakes (order of actions, ignoring renameTo, infinite copies).