ієрархія винятків, errors

— Привіт, Аміго!

— Привіт, Еллі! Як життя?

— Чудово дякую. А ти як?

— Супер, сьогодні вранці стільки нового розповіли.

— Так це ж чудово. Чи не втомився?

— Так, є така справа. Стомився трохи.

— Тоді тобі просто пощастило. Тому що хотіла тобі сьогодні дати велику та складну тему, але в останній момент передумала та вирішувала розповісти маленьку та легку.

— Маленьку та легку? Я готовий.

— Сьогодні ми з тобою детально розберемо тему винятків. Exception.

— Ти про обробку помилок?

— Вважати виняток помилками – це невірний підхід. Винятки більше схожі на звіт про те, що пішло не так. За допомогою якого можна запропонувати альтернативні сценарії дії.

Уся справа у методах. Коли ти викликаєш якийсь метод, він гарантовано повинен зробити те, для чого його викликали.

Коли метод з якихось причин не може зробити те, для чого його викликали, він зобов'язаний повідомити про це зухвалого.

Тобто. найгірше, що може статися - це коли метод не виконав свою роботу, і нікого про це не повідомив. Гірше за це не може бути нічого. Це втрата контролю за ситуацією.

Коли ти програміст-початківець, тобі здається, що ти викликаєш методи і вони обов'язково зроблять те, про що ти їх просиш.

Коли ти досвідчений програміст, ти знаєш, що можуть бути десятки факторів, які впливають на виконання методом своєї роботи, і можливі дуже багато різних випадків, коли метод не зміг виконати свою роботу.

З точки зору програміста, якщо в програмі стався збій, і вона закрилася – це в тисячу разів краща ситуація, ніж якщо в програмі стався збій, вона працює неправильно і користувач про це не підозрює.

— Як те, що програма щось показує неправильно, може бути гірше, ніж якщо програма закрилася, і всі дані загубилися?

— А чого ти взяв, що програма просто щось неправильно показує? Може, у неї всередині купа помилок і всі дані твоєї роботи з нею будуть безповоротно втрачені? Ти три години набирав текст, який не збережеться, тому що на другій хвилині роботи сталася помилка.

Коли програміст-початківець стикається з винятками, він засмучується.

Але насправді винятки показують йому всі ті сценарії поведінки, які він мав передбачити і не передбачив.

Ти можеш не обробляти винятки, і тоді — ти поганий програміст. Але якщо твої методи не викидають винятків, тоді взагалі не програміст, т.к. так і не зрозумів простої істини:

Метод або робить те, навіщо він написаний, або кидає виняток. Третього не дано!

— Добре, вірю. Обіцяю користуватися винятками.

— Чудово. Тоді давай я розповім тобі про ієрархію винятків:

Ієрархія винятків базується на чотирьох класах.

Найбільш базовий клас – це Throwable.

Від нього успадковано класи Error і Exception.

Від Exception успадкований RuntimeException.

Клас< Error є базовим класом для помилок Java-машини, таких як StackOverFlow, OutOfMemory , …

Виправити наслідки таких помилок програма зазвичай не може, і це призводить до її завершення.

Справді, що можна зробити, якщо для подальшої нормальної роботи програми не вистачає пам'яті або переповнився стек.

КласException є базовим для всіх звичайних винятків, які викидаються програмою. RuntimeException – це підкатегорія винятків Exception, до яких застосовуються інші правила.

— Це які?

— Саме зараз і розповім.

Як ти, напевно, пам'ятаєш, винятки поділяються на дві категорії checked (перевірені) та unchecked ( неперевірені).

Якщо метод викидає checked винятки, то метод, що викликає, повинен обернути виклик такого методу в блок try-catch. Ну, або прокинути виняток вище (своєму зухвалому), явно вказавши його в списку throws у сигнатурі методу.

На unchecked такі правила/обмеження не поширюються.

Так ось, всі винятки, успадковані від Exception, вважаються checked. Крім винятків, успадкованих від RuntimeException – вони unchecked.

— Ага. Пригадую, щось таке мені раніше розповідали.

— Аміго! Ієрархію виключень запитують на кожній співбесіді. Ще раз –на кожному. Ти маєш чудово знати цю тему.

— Ок. Я ще раз усе перечитаю та розберуся. Дякую, що допомагаєш мені, Еллі.