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 намагається викликати неіснуючий метод або метод з невірним аргументом.