Українська
Типові проблеми та перевірка
Типові проблеми та перевірка роботи
Якщо Gradle не запускається, спочатку перевірте JVM процесу Gradle та його версію. Якщо залежність не завантажується, прочитайте назву артефакту й адресу сховища. Повторний запуск без зміни причини не є способом виправлення конфігурації.
Помилка Type mismatch означає несумісні типи; наприклад, readln() повертає String, а не Int. Помилка пошуку MainKt часто пов’язана з назвою файла, пакетом або mainClass. Якщо кирилиця відображається неправильно, перевірте UTF-8 файла й консолі; не замінюйте текст знаками ?.
Знімок екрана
Disposable val age: Int = readln(); show actual compiler diagnostic.
Рис. 1.11. Помилка типу та посилання на рядок коду
Для кожної програми запишіть вхід, очікуваний результат, фактичний результат і висновок. Перевірте звичайний випадок, найменше допустиме значення та неправильний ввід. Якщо перша версія має обмеження, назвіть їх явно: це краще, ніж показувати один вдалий запуск як доказ універсальності.
Мінімальний протокол перевірки
Для тренування діагностики розгляньте три різні ситуації. У першій код не компілюється, у другій компілюється, але завершується винятком, у третій виконується без винятку, проте не відповідає потрібній формулі.
kotlin
// Навмисна помилка типу; окремий файл для діагностики.
fun main() {
val count: Int = "12"
println(count)
}Для такого файла потрібно виправити невідповідність String і Int до запуску. Додавання паузи в консоль або перевстановлення JDK не змінить причину помилки. Надалі текст "12" можна буде явно перетворити на число.
kotlin
// Навмисна помилка виконання; ввід "abc" неприпустимий.
fun main() {
println(readln().toInt())
}Ця програма коректна за типами, але не обробляє нечисловий ввід. Повідомлення містить тип винятку та посилання на рядок. Для обробки без аварійного завершення наступна тема вводить toIntOrNull().
kotlin
// Навмисна логічна помилка: очікується 2.5, а не 2.
fun main() {
val hours = 150 / 60
println(hours)
}Компілятор не знає, що автор очікує дробові години. Обидва операнди є цілими, тому результат 2 відповідає семантиці операції. Виправлення для цієї моделі – зробити один операнд дробовим, наприклад 150.0 / 60. Саме таблиця очікуваних результатів виявляє таку помилку.
Навмисно неправильні файли не включають до звичайної успішної збірки проєкту. Перевіряйте їх окремо, зберігайте діагностику та після експерименту повертайте робочий код. Це дозволяє відтворити навчальний дослід, не залишаючи в репозиторії випадково зламаний основний застосунок.
Відтворюваність означає, що інша людина отримує той самий результат за описаних умов. Для першого проєкту корисно мати коротку таблицю, що відокремлює інструменти від логіки. Стан «зібралося» не замінює перевірки правильного результату.
| Перевірка | Що має бути зафіксовано |
|---|---|
| Інструменти | Версії Kotlin, Gradle, JVM Gradle, JDK програми |
| Джерела | Назва головного файла й повна назва mainClass |
| Ввід | Точні рядки stdin або аргументи та одиниці |
| Очікування | Ручний розрахунок до запуску програми |
| Фактичний результат | Вивід, код завершення, відхилення |
| Повторення | Команда запуску з чистої копії проєкту |
Якщо консоль очікує введення, порожній рядок і кінець потоку – різні ситуації. Натискання Enter передає рядок нульової довжини; закриття стандартного вводу означає, що наступного рядка немає. readln() не повертає порожній рядок замість кінця потоку. Для контрольованого завершення використовують readlnOrNull(), який докладно розглянемо разом із null-безпекою.
Не виправляйте помилку шляхом випадкової заміни версій усіх інструментів одразу. Збережіть повідомлення, знайдіть першу причину, змініть один параметр і повторіть той самий тест. Коміт перед зміною дозволяє порівняти поведінку й повернутися до попереднього відтворюваного стану.