English
Summary
Conclusions
A path only describes a file's location, and a relative path depends on the process's working directory, so input and output paths are better passed as arguments. Text is stored as bytes in a specific encoding, and use and useLines close the resource when the block finishes, even on an exception. I/O errors are handled precisely, and an important file is updated through a fully written temporary file and a rename with an explicit atomicity policy. CSV has its own format contract, so split is suitable only for a deliberately restricted variant with validation of all lines. The kotlinx.serialization plugin generates serializers for classes annotated with @Serializable, and the Json settings define the schema, default values, and the reaction to unknown fields. A sealed hierarchy with a discriminator defines polymorphic encoding, and a type without built-in support, such as LocalDate, needs a custom serializer. A unit test is an executable contract with an Arrange–Act–Assert structure and an independently determined expected value. The Gradle report and coverage show what was executed, but correctness is proven by checks of behavior, boundaries, and corrupted data.
Self-check questions
- What does a relative path depend on?
- Why does an exists check not replace handling IOException?
- How do bytes differ from String.length?
- Why must you not return a Sequence from useLines?
- What guarantees does ATOMIC_MOVE give and not give?
- Why is split not a general CSV parser?
- Why does serialization have both a plugin and a runtime?
- When does ignoreUnknownKeys hide an error?
- Which type determines the polymorphic serializer?
- Why does LocalDate need an explicitly defined representation?
- What are the roles of kotlin.test, the Platform, and Jupiter?
- Why does coverage not prove correctness?