6 Java Exceptions які переслідують новачків у Java.
(Оригінал) (Я сам новачок і в Java і в English, тому буду радий критики та допомоги)
І раніше і зараз, я стикаюся з багатьма новачками в Java, у яких виникає проблема з декількома винятками, які часто зустрічаються, які я повинен пояснювати в черговий раз. Я вірю, що така ж проблема у інших Senior Java розробників, які намагаються допомогти новачкам впоратися з цими винятками. Таким чином, я писав цю статтю і для свого розвитку. Будь ласка, не соромтеся коментувати цю статтю або додавати винятки до наступного списку.
Це один з тих винятків, з таким повідомленням як
"Exception in thread "main" NoClassDefFoundError" , яке найчастіше зустрічає новачків Java розробників у світі програмування Java. Новачок пише програму, що виводить «Hello world!», переходить у командний рядок, набирає «java…», тисне enter і БАЦ! =). І з'ясування як змусити програму вивести «Hello world!» на монітор займає якийсь час.
NoClassDefFoundError відбувається, коли віртуальна машина Java (JVM) намагається отримати доступ до класу під час запуску і клас не знаходить, незважаючи на те, що цей же клас був знайдений під час компіляції. Найчастіше це виняток відбувається під час спроби виконати програму за допомогою команди java, а classpath не встановлений як треба. Ось опис причин, з яких виникає цей виняток.
- Клас не доступний -classpath.
- Перевизначено змінне середовище CLASSPATH. Перевірити наявність та коректність можна за допомогою команди Windows «set» .
Докладніше вирішення проблеми описано
тут.
Причому треба зрозуміти різницю між змінною оточення CLASSPATH та ключем інтерперетатора -classpath. Фахівці не рекомендують використовувати CLASSPATH. Найкращим способом вважається передача ключа -classpath інтерпретатору.
ClassNotFoundException це ще один виняток, який ставати кошмаром для новачка, як тільки він починає програмувати. Цікаво, що у середнього Java розробника часто
виникає плутанина між ClassNotFoundException і NoClassDefFoundError винятками . І, таким чином, різниця між цими двома винятками залишається
одним з питань, що найчастіше ставляться в співбесідах на позицію Junior-a .
ClassNotFoundException виникає коли JVM намагається завантажити певний клас і не знаходить його в classpath. Одне з найпоширеніших місць, де новачок Java розробник стикається з ним вперше, підключення до бази даних, використовуючи бібліотеку JDBC. Там ми спробуємо завантажити драйвер, використовуючи код типу Class.forName("JDBCdriver"). Хороша стаття про ClassNotFoundException лежить
тут . Спробувати зрозуміти концепцію
Java Classloaders — це найефективніший метод розібратися з цією проблемою. Ви можете почитати
як налаштувати Java classpath у Win / Unix середовищі . Як зазначено в
java docs , виняток відбувається у таких випадках:
- При спробі завантажити клас, використовуючи метод Class.forName, а файл .class відсутній у classpath. Це найбільш поширений сценарій із трьох перерахованих тут.
- Коли завантажувач класів намагається завантажити клас за допомогою методу loadClass.
- Коли завантажувач класів намагається завантажити клас, використовуючи findSystemClass.
Це виняток простіше для розуміння новачками, ніж перші два. Тим більше,
це виняток легко ідентифікується т.к. у разі виникнення, у повідомленні про виникнення винятку
вказується номер рядка у програмі, де воно сталося. Це виняток виникає, коли JVM намагається отримати доступ до об'єкта або намагається викликати метод об'єкта, а замість посилання на об'єкт отримує null. Також у Java Doc вказані такі причини:
- Доступ або зміни методу на об'єкті, який є недійсним. (тобто замість посилання на об'єкт JVM отримує null)
- Отримання довжини масиву, коли він є недійсним. (Не ініціалізований наприклад)
- Спроба доступу до неіснуючого елемента масиву типу Object. (тобто коли замість посилання на об'єкт елемент масиву містить null)
Найбільш простий метод уникнути цього виключення, використання перевірки не-NULL. Тим не менш, рано чи пізно, це стає практикою Java розробки, і ви скрізь знаходитимете перевірки на не-NULL.Цікаво, що вставляти скрізь
перевірки на не-NULL, не вважається хорошим стилем програмування . І основною причиною використання перевірки не-NULL є те, що розробник хоче передати null об'єкт у разі збою або помилки. Натомість
хороша практика програмування , яку повинні використовувати програмісти, це
повернення порожнього об'єкта, замість значення null , як основна логіка поведінки програми у разі помилки. Проте прийняття цієї практики програмування складніше, ніж здається.
Про це є гарна стаття на нашому ресурсі.
Це ще один знайомий новачкам виняток, що виникає при спробі приведення об'єкта до класу, який не є його підкласом. Знову ж таки, це досить легко зрозуміти, ідентифікувати і просто виправити. Один із шляхів уникнути цього виключення, коли тип об'єкта невідомий під час виконання, є використання
"InstanceOf" для перевірки того, що об'єкт є екземпляром певного класу.
Цей виняток не вимагає пояснень і відбувається, коли JVM намагається отримати доступ до елемента масиву з неіснуючим індексом, наприклад, негативним (-1) або більше або рівному розміру масиву.
Воно досить легко розуміється, визначається та виправляється . Наприклад при створенні циклу
for (i = 0; i <= cmd_stack.length; i++) System.out.println(cmd_stack[i]); виникає виняток, тому що в масиві індекси йдуть з 0, а метод length повертає кількість елементів, а кількість більша на 1 ніж значення останнього індексу. Правильно використати
for (i = 0; i < cmd_stack.length; i++) System.out.println(cmd_stack[i]);
Цей виняток менш поширений і досить легко розуміється, виявляється і усувається. Воно виникає коли JVM намагається викликати неіснуючий метод або метод з невірним аргументом.
ПЕРЕЙДІТЬ В ПОВНУ ВЕРСІЮ