Это первая часть статьи, посвященной такому языковому механизму Java как исключения (вторая (checked/unchecked) вот). Она имеет вводный характер и рассчитана на начинающих разработчиков или тех, кто только приступает к изучению языка.
Также я веду курс «Scala for Java Developers» на платформе для онлайн-образования udemy.com (аналог Coursera/EdX).
1. Ключевые слова: try, catch, finally, throw, throws
2. Почему используем System.err, а не System.out
3. Компилятор требует вернуть результат (или требует молчать)
4. Нелокальная передача управления (nonlocal control transfer)
5. try + catch (catch — полиморфен)
6. try + catch + catch + …
7. try + finally
8. try + catch + finally
9. Вложенные try + catch + finally
1. Ключевые слова: try, catch, finally, throw, throws
Механизм исключительных ситуаций в Java поддерживается пятью ключевыми словами
- try
- catch
- finally
- throw
- throws
«Магия» (т.е. некоторое поведение никак не отраженное в исходном коде и потому неповторяемое пользователем) исключений #1 заключается в том, что catch, throw, throws можно использовать исключительно с java.lang.Throwable или его потомками.
throws:
Годится
public class App {
public static void main(String[] args) throws Throwable {}
}
Не годится
public class App {
public static void main(String[] args) throws String {}
}
>> COMPILATION ERROR: Incompatible types: required 'java.lang.Throwable', found: 'java.lang.String'
catch:
Годится
public class App {
public static void main(String[] args) {
try {
} catch (Throwable t) {}
}
}
Не годится
public class App {
public static void main(String[] args) {
try {
} catch (String s) {}
}
}
>> COMPILATION ERROR: Incompatible types: required 'java.lang.Throwable', found: 'java.lang.String'
throw:
Годится
public class App {
public static void main(String[] args) {
// Error - потомок Throwable
throw new Error();
}
}
Не годится
public class App {
public static void main(String[] args) {
throw new String("Hello!");
}
}
>> COMPILATION ERROR: Incompatible types: required 'java.lang.Throwable', found: 'java.lang.String'
Кроме того, throw требуется не-null аргумент, иначе NullPointerException в момент выполнения
public class App {
public static void main(String[] args) {
throw null;
}
}
>> RUNTIME ERROR: Exception in thread "main" java.lang.NullPointerException
throw и new — это две независимых операции. В следующем коде мы независимо создаем объект исключения и «бросаем» его
public class App {
public static void main(String[] args) {
Error ref = new Error(); // создаем экземпляр
throw ref; // "бросаем" его
}
}
>> RUNTIME ERROR: Exception in thread "main" java.lang.Error
Однако, попробуйте проанализировать вот это
public class App {
public static void main(String[] args) {
f(null);
}
public static void f(NullPointerException e) {
try {
throw e;
} catch (NullPointerException npe) {
f(npe);
}
}
}
>> RUNTIME ERROR: Exception in thread "main" java.lang.StackOverflowError
2. Почему используем System.err, а не System.out
System.out — buffered-поток вывода, а System.err — нет. Таким образом вывод может быть как таким
public class App {
public static void main(String[] args) {
System.out.println("sout");
throw new Error();
}
}
>> RUNTIME ERROR: Exception in thread "main" java.lang.Error
>> sout
Так и вот таким (err обогнало out при выводе в консоль)
public class App {
public static void main(String[] args) {
System.out.println("sout");
throw new Error();
}
}
>> sout
>> RUNTIME ERROR: Exception in thread "main" java.lang.Error
Давайте это нарисуем
буфер сообщений
+----------------+
+->| msg2 msg1 msg0 | --> out
/ +----------------+
/ +-> +--------+
ВАШЕ ПРИЛОЖЕНИЕ | КОНСОЛЬ|
+-> +--------+
/
+------------------------> err
нет буфера, сразу печатаем
когда Вы пишете в System.err — ваше сообщение тут же выводится на консоль, но когда пишете в System.out, то оно может на какое-то время быть буферизированно. Stacktrace необработанного исключение выводится через System.err, что позволяет им обгонять «обычные» сообщения.
3. Компилятор требует вернуть результат (или требует молчать)
Если в объявлении метода сказано, что он возвращает НЕ void, то компилятор зорко следит, что бы мы вернули экземпляр требуемого типа или экземпляр типа, который можно неявно привести к требуемому
public class App {
public double sqr(double arg) { // надо double
return arg * arg; // double * double - это double
}
}
public class App {
public double sqr(double arg) { // надо double
int k = 1; // есть int
return k; // можно неявно преобразовать int в double
}
}
// на самом деле, компилятор сгенерирует байт-код для следующих исходников
public class App {
public double sqr(double arg) { // надо double
int k = 1; // есть int
return (double) k; // явное преобразование int в double
}
}
вот так не пройдет (другой тип)
public class App {
public static double sqr(double arg) {
return "hello!";
}
}
>> COMPILATION ERROR: Incompatible types. Required: double. Found: java.lang.String
Вот так не выйдет — нет возврата
public class App {
public static double sqr(double arg) {
}
}
>> COMPILATION ERROR: Missing return statement
и вот так не пройдет (компилятор не может удостовериться, что возврат будет)
public class App {
public static double sqr(double arg) {
if (System.currentTimeMillis() % 2 == 0) {
return arg * arg; // если currentTimeMillis() - четное число, то все ОК
}
// а если нечетное, что нам возвращать?
}
}
>> COMPILATION ERROR: Missing return statement
Компилятор отслеживает, что бы мы что-то вернули, так как иначе непонятно, что должна была бы напечатать данная программа
public class App {
public static void main(String[] args) {
double d = sqr(10.0); // ну, и чему равно d?
System.out.println(d);
}
public static double sqr(double arg) {
// nothing
}
}
>> COMPILATION ERROR: Missing return statement
Из-забавного, можно ничего не возвращать, а «повесить метод»
public class App {
public static double sqr(double arg) {
while (true); // Удивительно, но КОМПИЛИРУЕТСЯ!
}
}
Тут в d никогда ничего не будет присвоено, так как метод sqr повисает
public class App {
public static void main(String[] args) {
double d = sqr(10.0); // sqr - навсегда "повиснет", и
System.out.println(d); // d - НИКОГДА НИЧЕГО НЕ БУДЕТ ПРИСВОЕНО!
}
public static double sqr(double arg) {
while (true); // Вот тут мы на века "повисли"
}
}
Компилятор пропустит «вилку» (таки берем в квадрат ИЛИ висим)
public class App {
public static double sqr(double arg) {
if (System.currentTimeMillis() % 2 == 0) {
return arg * arg; // ну ладно, вот твой double
} else {
while (true); // а тут "виснем" навсегда
}
}
}
Но механизм исключений позволяет НИЧЕГО НЕ ВОЗВРАЩАТЬ!
public class App {
public static double sqr(double arg) {
throw new RuntimeException();
}
}
Итак, у нас есть ТРИ варианта для компилятора
public class App {
public static double sqr(double arg) {// согласно объявлению метода ты должен вернуть double
long time = System.currentTimeMillis();
if (time % 2 == 0) {
return arg * arg; // ок, вот твой double
} else if (time % 2 == 1) { {
while (true); // не, я решил "повиснуть"
} else {
throw new RuntimeException(); // или бросить исключение
}
}
}
Но КАКОЙ ЖЕ double вернет функция, бросающая RuntimeException?
А НИКАКОЙ!
public class App {
public static void main(String[] args) {
// sqr - "сломается" (из него "выскочит" исключение),
double d = sqr(10.0); // выполнение метода main() прервется в этой строчке и
// d - НИКОГДА НИЧЕГО НЕ БУДЕТ ПРИСВОЕНО!
System.out.println(d); // и печатать нам ничего не придется!
}
public static double sqr(double arg) {
throw new RuntimeException(); // "бросаем" исключение
}
}
>> RUNTIME ERROR: Exception in thread "main" java.lang.RuntimeException
Подытожим: бросаемое исключение — это дополнительный возвращаемый тип. Если ваш метод объявил, что возвращает double, но у вас нет double — можете бросить исключение. Если ваш метод объявил, что ничего не возвращает (void), но у вам таки есть что сказать — можете бросить исключение.
Давайте рассмотрим некоторый пример из практики.
Задача: реализовать функцию, вычисляющую площадь прямоугольника
public static int area(int width, int height) {...}
важно, что задание звучит именно так, в терминах предметной области — «вычислить площадь прямоугольника», а не в терминах решения «перемножить два числа»:
public static int area(int width, int height) {
return width * height; // тут просто перемножаем
}
Вопрос: что делать, если мы обнаружили, что хотя бы один из аргументов — отрицательное число?
Если просто умножить, то мы пропустили ошибочные данные дальше. Что еще хуже, возможно, мы «исправили ситуацию» — сказали что площадь прямоугольника с двумя отрицательными сторонами -10 и -20 = 200.
Мы не можем ничего не вернуть
public static int area(int width, int height) {
if (width < 0 || height < 0) {
// у вас плохие аргументы, извините
} else {
return width * height;
}
}
>> COMPILATION ERROR: Missing return statement
Можно, конечно, отписаться в консоль, но кто ее будет читать и как определить где была поломка. При чем, вычисление то продолжится с неправильными данными
public static int area(int width, int height) {
if (width < 0 || height < 0) {
System.out.println("Bad ...");
}
return width * height;
}
Можно вернуть специальное значение, показывающее, что что-то не так (error code), но кто гарантирует, что его прочитают, а не просто воспользуются им?
public static int area(int width, int height) {
if (width < 0 || height < 0) {
return -1; // специальное "неправильное" значение площади
}
return width * height;
}
Можем, конечно, целиком остановить виртуальную машину
public static int area(int width, int height) {
if (width < 0 || height < 0) {
System.exit(0);
}
return width * height;
}
Но «правильный путь» таков: если обнаружили возможное некорректное поведение, то
1. Вычисления остановить, сгенерировать сообщение-поломку, которое трудно игнорировать, предоставить пользователю информацию о причине, предоставить пользователю возможность все починить (загрузить белье назад и повторно нажать кнопку старт)
public static int area(int width, int height) {
if (width < 0 || height < 0) {
throw new IllegalArgumentException("Negative sizes: w = " + width + ", h = " + height);
}
return width * height;
}
4. Нелокальная передача управления (nonlocal control transfer)
Механизм исключительных ситуация (исключений) — это механизм НЕЛОКАЛЬНОЙ ПЕРЕДАЧИ УПРАВЛЕНИЯ.
Что под этим имеется в виду?
Программа, в ходе своего выполнения (точнее исполнения инструкций в рамках отдельного потока), оперирует стеком («стопкой») фреймов. Передача управления осуществляется либо в рамках одного фрейма
public class App {
public static void main(String[] args) {
// Пример: ОПЕРАТОР ПОСЛЕДОВАТЕЛЬНОСТИ
int x = 42; // первый шаг
int y = x * x; // второй шаг
x = x * y; // третий шаг
...
}
}
public class App {
public static void main(String[] args) {
// Пример: ОПЕРАТОР ВЕТВЛЕНИЯ
if (args.length > 2) { первый шаг
// второй шаг или тут
...
} else {
// или тут
...
}
// третий шаг
...
}
}
public class App {
public static void main(String[] args) {
// Пример: ОПЕРАТОР ЦИКЛА do..while
int x = 1;
do {
...
} while (x++ < 10);
...
}
}
и другие операторы.
Либо передача управления происходит в «стопке» фреймов между СОСЕДНИМИ фреймами
- вызов метода: создаем новый фрейм, помещаем его на верхушку стека и переходим в него
- выход из метода: возвращаемся к предыдущему фрейму (через return или просто кончились инструкции в методе)
return — выходим из ОДНОГО фрейма (из фрейма #4(метод h()))
public class App {
public static void main(String[] args) {
System.err.println("#1.in");
f(); // создаем фрейм, помещаем в стек, передаем в него управление
System.err.println("#1.out"); // вернулись
} // выходим из текущего фрейма, кончились инструкции
public static void f() {
System.err.println(". #2.in");
g(); // создаем фрейм, помещаем в стек, передаем в него управление
System.err.println(". #2.out"); //вернулись
} // выходим из текущего фрейма, кончились инструкции
public static void g() {
System.err.println(". . #3.in");
h(); // создаем фрейм, помещаем в стек, передаем в него управление
System.err.println(". . #3.out"); // вернулись
} // выходим из текущего фрейма, кончились инструкции
public static void h() {
System.err.println(". . . #4.in");
if (true) {
System.err.println(". . . #4.RETURN");
return; // выходим из текущего фрейма по 'return'
}
System.err.println(". . . #4.out"); // ПРОПУСКАЕМ
}
}
>> #1.in
>> . #2.in
>> . . #3.in
>> . . . #4.in
>> . . . #4.RETURN
>> . . #3.out
>> . #2.out
>> #1.out
throw — выходим из ВСЕХ фреймов
public class App {
public static void main(String[] args) {
System.err.println("#1.in");
f(); // создаем фрейм, помещаем в стек, передаем в него управление
System.err.println("#1.out"); // ПРОПУСТИЛИ!
}
public static void f() {
System.err.println(". #2.in");
g(); // создаем фрейм, помещаем в стек, передаем в него управление
System.err.println(". #2.out"); // ПРОПУСТИЛИ!
}
public static void g() {
System.err.println(". . #3.in");
h(); // создаем фрейм, помещаем в стек, передаем в него управление
System.err.println(". . #3.out"); // ПРОПУСТИЛИ!
}
public static void h() {
System.err.println(". . . #4.in");
if (true) {
System.err.println(". . . #4.THROW");
throw new Error(); // выходим со всей пачки фреймов ("раскрутка стека") по 'throw'
}
System.err.println(". . . #4.out"); // ПРОПУСТИЛИ!
}
}
>> #1.in
>> . #2.in
>> . . #3.in
>> . . . #4.in
>> . . . #4.THROW
>> RUNTIME ERROR: Exception in thread "main" java.lang.Error
При помощи catch мы можем остановить летящее исключение (причина, по которой мы автоматически покидаем фреймы).
Останавливаем через 3 фрейма, пролетаем фрейм #4(метод h()) + пролетаем фрейм #3(метод g()) + фрейм #2(метод f())
public class App {
public static void main(String[] args) {
System.err.println("#1.in");
try {
f(); // создаем фрейм, помещаем в стек, передаем в него управление
} catch (Error e) { // "перехватили" "летящее" исключение
System.err.println("#1.CATCH"); // и работаем
}
System.err.println("#1.out"); // работаем дальше
}
public static void f() {
System.err.println(". #2.in");
g(); // создаем фрейм, помещаем в стек, передаем в него управление
System.err.println(". #2.out"); // ПРОПУСТИЛИ!
}
public static void g() {
System.err.println(". . #3.in");
h(); // создаем фрейм, помещаем в стек, передаем в него управление
System.err.println(". . #3.out"); // ПРОПУСТИЛИ!
}
public static void h() {
System.err.println(". . . #4.in");
if (true) {
System.err.println(". . . #4.THROW");
throw new Error(); // выходим со всей пачки фреймов ("раскрутка стека") по 'throw'
}
System.err.println(". . . #4.out"); // ПРОПУСТИЛИ!
}
}
>> #1.in
>> . #2.in
>> . . #3.in
>> . . . #4.in
>> . . . #4.THROW
>> #1.CATCH
>> #1.out
Обратите внимание, стандартный сценарий работы был восстановлен в методе main() (фрейм #1)
Останавливаем через 2 фрейма, пролетаем фрейм #4(метод h()) + пролетаем фрейм #3(метод g())
public class App {
public static void main(String[] args) {
System.err.println("#1.in");
f(); // создаем фрейм, помещаем в стек, передаем в него управление
System.err.println("#1.out"); // вернулись и работаем
}
public static void f() {
System.err.println(". #2.in");
try {
g(); // создаем фрейм, помещаем в стек, передаем в него управление
} catch (Error e) { // "перехватили" "летящее" исключение
System.err.println(". #2.CATCH"); // и работаем
}
System.err.println(". #2.out"); // работаем дальше
}
public static void g() {
System.err.println(". . #3.in");
h(); // создаем фрейм, помещаем в стек, передаем в него управление
System.err.println(". . #3.out"); // ПРОПУСТИЛИ!
}
public static void h() {
System.err.println(". . . #4.in");
if (true) {
System.err.println(". . . #4.THROW");
throw new Error(); // выходим со всей пачки фреймов ("раскрутка стека") по 'throw'
}
System.err.println(". . . #4.out"); // ПРОПУСТИЛИ!
}
}
>> #1.in
>> . #2.in
>> . . #3.in
>> . . . #4.in
>> . . . #4.THROW
>> . #2.CATCH
>> . #2.out
>> #1.out
Останавливаем через 1 фрейм (фактически аналог return, просто покинули фрейм «другим образом»)
public class App {
public static void main(String[] args) {
System.err.println("#1.in");
f(); // создаем фрейм, помещаем в стек, передаем в него управление
System.err.println("#1.out"); // вернулись и работаем
}
public static void f() {
System.err.println(". #2.in");
g(); // создаем фрейм, помещаем в стек, передаем в него управление
System.err.println(". #2.out"); // вернулись и работаем
}
public static void g() {
System.err.println(". . #3.in");
try {
h(); // создаем фрейм, помещаем в стек, передаем в него управление
} catch (Error e) { // "перехватили" "летящее" исключение
System.err.println(". . #3.CATCH"); // и работаем
}
System.err.println(". . #3.out"); // работаем дальше
}
public static void h() {
System.err.println(". . . #4.in");
if (true) {
System.err.println(". . . #4.THROW");
throw new Error(); // выходим со всей пачки фреймов ("раскрутка стека") по 'throw'
}
System.err.println(". . . #4.out"); // ПРОПУСТИЛИ!
}
}
>> #1.in
>> . #2.in
>> . . #3.in
>> . . . #4.in
>> . . . #4.THROW
>> . . #3.CATCH
>> . . #3.out
>> . #2.out
>> #1.out
Итак, давайте сведем все на одну картинку
// ---Используем RETURN--- // ---Используем THROW---
// Выход из 1-го фрейма // Выход из ВСЕХ (из 4) фреймов
#1.in #1.in
. #2.in . #2.in
. . #3.in . . #3.in
. . . #4.in . . . #4.in
. . . #4.RETURN . . . #4.THROW
. . #3.out RUNTIME EXCEPTION: Exception in thread "main" java.lang.Error
. #2.out
#1.out
// ---Используем THROW+CATCH---
// Выход из 3-х фреймов // Выход из 2-х фреймов // Выход из 1-го фрейма
#1.in #1.in #1.in
. #2.in . #2.in . #2.in
. . #3.in . . #3.in . . #3.in
. . . #4.in . . . #4.in . . . #4.in
. . . #4.THROW . . . #4.THROW . . . #4.THROW
#1.CATCH . #2.CATCH . . #3.CATCH
#1.out . #2.out . . #3.out
#1.out . #2.out
#1.out
5. try + catch (catch — полиморфен)
Напомним иерархию исключений
Object
|
Throwable
/
Error Exception
|
RuntimeException
То, что исключения являются объектами важно для нас в двух моментах
1. Они образуют иерархию с корнем java.lang.Throwable (java.lang.Object — предок java.lang.Throwable, но Object — уже не исключение)
2. Они могут иметь поля и методы (в этой статье это не будем использовать)
По первому пункту: catch — полиморфная конструкция, т.е. catch по типу Parent перехватывает летящие экземпляры любого типа, который является Parent-ом (т.е. экземпляры непосредственно Parent-а или любого потомка Parent-а)
public class App {
public static void main(String[] args) {
try {
System.err.print(" 0");
if (true) {throw new RuntimeException();}
System.err.print(" 1");
} catch (Exception e) { // catch по Exception ПЕРЕХВАТЫВАЕТ RuntimeException
System.err.print(" 2");
}
System.err.println(" 3");
}
}
>> 0 2 3
Даже так: в блоке catch мы будем иметь ссылку типа Exception на объект типа RuntimeException
public class App {
public static void main(String[] args) {
try {
throw new RuntimeException();
} catch (Exception e) {
if (e instanceof RuntimeException) {
RuntimeException re = (RuntimeException) e;
System.err.print("Это RuntimeException на самом деле!!!");
} else {
System.err.print("В каком смысле не RuntimeException???");
}
}
}
}
>> Это RuntimeException на самом деле!!!
catch по потомку не может поймать предка
public class App {
public static void main(String[] args) throws Exception { // пока игнорируйте 'throws'
try {
System.err.print(" 0");
if (true) {throw new Exception();}
System.err.print(" 1");
} catch (RuntimeException e) {
System.err.print(" 2");
}
System.err.print(" 3");
}
}
>> 0
>> RUNTIME EXCEPTION: Exception in thread "main" java.lang.Exception
catch по одному «брату» не может поймать другого «брата» (Error и Exception не находятся в отношении предок-потомок, они из параллельных веток наследования от Throwable)
public class App {
public static void main(String[] args) {
try {
System.err.print(" 0");
if (true) {throw new Error();}
System.err.print(" 1");
} catch (Exception e) {
System.err.print(" 2");
}
System.err.print(" 3");
}
}
>> 0
>> RUNTIME EXCEPTION: Exception in thread "main" java.lang.Error
По предыдущим примерам — надеюсь вы обратили внимание, что если исключение перехвачено, то JVM выполняет операторы идущие ПОСЛЕ последних скобок try+catch.
Но если не перехвачено, то мы
1. не заходим в блок catch
2. покидаем фрейм метода с летящим исключением
А что будет, если мы зашли в catch, и потом бросили исключение ИЗ catch?
public class App {
public static void main(String[] args) {
try {
System.err.print(" 0");
if (true) {throw new RuntimeException();}
System.err.print(" 1");
} catch (RuntimeException e) { // перехватили RuntimeException
System.err.print(" 2");
if (true) {throw new Error();} // но бросили Error
}
System.err.println(" 3"); // пропускаем - уже летит Error
}
}
>> 0 2
>> RUNTIME EXCEPTION: Exception in thread "main" java.lang.Error
В таком случае выполнение метода тоже прерывается (не печатаем «3»). Новое исключение не имеет никакого отношения к try-catch
Мы можем даже кинуть тот объект, что у нас есть «на руках»
public class App {
public static void main(String[] args) {
try {
System.err.print(" 0");
if (true) {throw new RuntimeException();}
System.err.print(" 1");
} catch (RuntimeException e) { // перехватили RuntimeException
System.err.print(" 2");
if (true) {throw e;} // и бросили ВТОРОЙ раз ЕГО ЖЕ
}
System.err.println(" 3"); // пропускаем - опять летит RuntimeException
}
}
>> 0 2
>> RUNTIME EXCEPTION: Exception in thread "main" java.lang.RuntimeException
И мы не попадем в другие секции catch, если они есть
public class App {
public static void main(String[] args) {
try {
System.err.print(" 0");
if (true) {throw new RuntimeException();}
System.err.print(" 1");
} catch (RuntimeException e) { // перехватили RuntimeException
System.err.print(" 2");
if (true) {throw new Error();} // и бросили новый Error
} catch (Error e) { // хотя есть cath по Error "ниже", но мы в него не попадаем
System.err.print(" 3");
}
System.err.println(" 4");
}
}
>> 0 2
>> RUNTIME EXCEPTION: Exception in thread "main" java.lang.Error
Обратите внимание, мы не напечатали «3», хотя у нас летит Error а «ниже» расположен catch по Error. Но важный момент в том, что catch имеет отношение исключительно к try-секции, но не к другим catch-секциям.
Как покажем ниже — можно строить вложенные конструкции, но вот пример, «исправляющий» эту ситуацию
public class App {
public static void main(String[] args) {
try {
System.err.print(" 0");
if (true) {throw new RuntimeException();}
System.err.print(" 1");
} catch (RuntimeException e) { // перехватили RuntimeException
System.err.print(" 2.1");
try {
System.err.print(" 2.2");
if (true) {throw new Error();} // и бросили новый Error
System.err.print(" 2.3");
} catch (Throwable t) { // перехватили Error
System.err.print(" 2.4");
}
System.err.print(" 2.5");
} catch (Error e) { // хотя есть cath по Error "ниже", но мы в него не попадаем
System.err.print(" 3");
}
System.err.println(" 4");
}
}
>> 0 2.1 2.2 2.4 2.5 4
6. try + catch + catch + …
Как вы видели, мы можем расположить несколько catch после одного try.
Но есть такое правило — нельзя ставить потомка после предка! (RuntimeException после Exception)
public class App {
public static void main(String[] args) {
try {
} catch (Exception e) {
} catch (RuntimeException e) {
}
}
}
>> COMPILATION ERROR: Exception 'java.lang.RuntimeException' has alredy been caught
Ставить брата после брата — можно (RuntimeException после Error)
public class App {
public static void main(String[] args) {
try {
} catch (Error e) {
} catch (RuntimeException e) {
}
}
}
Как происходит выбор «правильного» catch? Да очень просто — JVM идет сверху-вниз до тех пор, пока не найдет такой catch что в нем указано ваше исключение или его предок — туда и заходит. Ниже — не идет.
public class App {
public static void main(String[] args) {
try {
throw new Exception();
} catch (RuntimeException e) {
System.err.println("catch RuntimeException");
} catch (Exception e) {
System.err.println("catch Exception");
} catch (Throwable e) {
System.err.println("catch Throwable");
}
System.err.println("next statement");
}
}
>> catch Exception
>> next statement
Выбор catch осуществляется в runtime (а не в compile-time), значит учитывается не тип ССЫЛКИ (Throwable), а тип ССЫЛАЕМОГО (Exception)
public class App {
public static void main(String[] args) {
try {
Throwable t = new Exception(); // ссылка типа Throwable указывает на объект типа Exception
throw t;
} catch (RuntimeException e) {
System.err.println("catch RuntimeException");
} catch (Exception e) {
System.err.println("catch Exception");
} catch (Throwable e) {
System.err.println("catch Throwable");
}
System.err.println("next statement");
}
}
>> catch Exception
>> next statement
7. try + finally
finally-секция получает управление, если try-блок завершился успешно
public class App {
public static void main(String[] args) {
try {
System.err.println("try");
} finally {
System.err.println("finally");
}
}
}
>> try
>> finally
finally-секция получает управление, даже если try-блок завершился исключением
public class App {
public static void main(String[] args) {
try {
throw new RuntimeException();
} finally {
System.err.println("finally");
}
}
}
>> finally
>> Exception in thread "main" java.lang.RuntimeException
finally-секция получает управление, даже если try-блок завершился директивой выхода из метода
public class App {
public static void main(String[] args) {
try {
return;
} finally {
System.err.println("finally");
}
}
}
>> finally
finally-секция НЕ вызывается только если мы «прибили» JVM
public class App {
public static void main(String[] args) {
try {
System.exit(42);
} finally {
System.err.println("finally");
}
}
}
>> Process finished with exit code 42
System.exit(42) и Runtime.getRuntime().exit(42) — это синонимы
public class App {
public static void main(String[] args) {
try {
Runtime.getRuntime().exit(42);
} finally {
System.err.println("finally");
}
}
}
>> Process finished with exit code 42
И при Runtime.getRuntime().halt(42) — тоже не успевает зайти в finally
public class App {
public static void main(String[] args) {
try {
Runtime.getRuntime().halt(42);
} finally {
System.err.println("finally");
}
}
}
>> Process finished with exit code 42
exit() vs halt()
javadoc: java.lang.Runtime#halt(int status)
… Unlike the exit method, this method does not cause shutdown hooks to be started and does not run uninvoked finalizers if finalization-on-exit has been enabled. If the shutdown sequence has already been initiated then this method does not wait for any running shutdown hooks or finalizers to finish their work.
Однако finally-секция не может «починить» try-блок завершившийся исключение (заметьте, «more» — не выводится в консоль)
public class App {
public static void main(String[] args) {
try {
System.err.println("try");
if (true) {throw new RuntimeException();}
} finally {
System.err.println("finally");
}
System.err.println("more");
}
}
>> try
>> finally
>> Exception in thread "main" java.lang.RuntimeException
Трюк с «if (true) {…}» требуется, так как иначе компилятор обнаруживает недостижимый код (последняя строка) и отказывается его компилировать
public class App {
public static void main(String[] args) {
try {
System.err.println("try");
throw new RuntimeException();
} finally {
System.err.println("finally");
}
System.err.println("more");
}
}
>> COMPILER ERROR: Unrechable statement
И finally-секция не может «предотвратить» выход из метода, если try-блок вызвал return («more» — не выводится в консоль)
public class App {
public static void main(String[] args) {
try {
System.err.println("try");
if (true) {return;}
} finally {
System.err.println("finally");
}
System.err.println("more");
}
}
>> try
>> finally
Однако finally-секция может «перебить» throw/return при помощи другого throw/return
public class App {
public static void main(String[] args) {
System.err.println(f());
}
public static int f() {
try {
return 0;
} finally {
return 1;
}
}
}
>> 1
public class App {
public static void main(String[] args) {
System.err.println(f());
}
public static int f() {
try {
throw new RuntimeException();
} finally {
return 1;
}
}
}
>> 1
public class App {
public static void main(String[] args) {
System.err.println(f());
}
public static int f() {
try {
return 0;
} finally {
throw new RuntimeException();
}
}
}
>> Exception in thread "main" java.lang.RuntimeException
public class App {
public static void main(String[] args) {
System.err.println(f());
}
public static int f() {
try {
throw new Error();
} finally {
throw new RuntimeException();
}
}
}
>> Exception in thread "main" java.lang.RuntimeException
finally-секция может быть использована для завершающего действия, которое гарантированно будет вызвано (даже если было брошено исключение или автор использовал return) по окончании работы
// open some resource
try {
// use resource
} finally {
// close resource
}
Например для освобождения захваченной блокировки
Lock lock = new ReentrantLock();
...
lock.lock();
try {
// some code
} finally {
lock.unlock();
}
Или для закрытия открытого файлового потока
InputStream input = new FileInputStream("...");
try {
// some code
} finally {
input.close();
}
Специально для этих целей в Java 7 появилась конструкция try-with-resources, ее мы изучим позже.
Вообще говоря, в finally-секция нельзя стандартно узнать было ли исключение.
Конечно, можно постараться написать свой «велосипед»
public class App {
public static void main(String[] args) {
System.err.println(f());
}
public static int f() {
long rnd = System.currenttimeMillis();
boolean finished = false;
try {
if (rnd % 3 == 0) {
throw new Error();
} else if (rnd % 3 == 1) {
throw new RuntimeException();
} else {
// nothing
}
finished = true;
} finally {
if (finished) {
// не было исключений
} else {
// было исключение, но какое?
}
}
}
}
Не рекомендуемые практики
— return из finally-секции (можем затереть исключение из try-блока)
— действия в finally-секции, которые могут бросить исключение (можем затереть исключение из try-блока)
8. try + catch + finally
Нет исключения
public class App {
public static void main(String[] args) {
try {
System.err.print(" 0");
// nothing
System.err.print(" 1");
} catch(Error e) {
System.err.print(" 2");
} finally {
System.err.print(" 3");
}
System.err.print(" 4");
}
}
>> 0 1 3 4
Не заходим в catch, заходим в finally, продолжаем после оператора
Есть исключение и есть подходящий catch
public class App {
public static void main(String[] args) {
try {
System.err.print(" 0");
if (true) {throw new Error();}
System.err.print(" 1");
} catch(Error e) {
System.err.print(" 2");
} finally {
System.err.print(" 3");
}
System.err.print(" 4");
}
}
>> 0 2 3 4
Заходим в catch, заходим в finally, продолжаем после оператора
Есть исключение но нет подходящего catch
public class App {
public static void main(String[] args) {
try {
System.err.print(" 0");
if (true) {throw new RuntimeException();}
System.err.print(" 1");
} catch(Error e) {
System.err.print(" 2");
} finally {
System.err.print(" 3");
}
System.err.print(" 4");
}
}
>> 0 3
>> RUNTIME ERROR: Exception in thread "main" java.lang.RuntimeException
Не заходим в catch, заходим в finally, не продолжаем после оператора — вылетаем с неперехваченным исключением
9. Вложенные try + catch + finally
Операторы обычно допускают неограниченное вложение.
Пример с if
public class App {
public static void main(String[] args) {
if (args.length > 1) {
if (args.length > 2) {
if (args.length > 3) {
...
}
}
}
}
}
Пример с for
public class App {
public static void main(String[] args) {
for (int i = 0; i < 10; i++) {
for (int j = 0; j < 10; i++) {
for (int k = 0; k < 10; k++) {
...
}
}
}
}
}
Суть в том, что try-cacth-finally тоже допускает неограниченное вложение.
Например вот так
public class App {
public static void main(String[] args) {
try {
try {
try {
...
} catch (Exception e) {
} finally {}
} catch (Exception e) {
} finally {}
} catch (Exception e) {
} finally {}
}
}
Или даже вот так
public class App {
public static void main(String[] args) {
try {
try {
...
} catch (Exception e) {
...
} finally {
...
}
} catch (Exception e) {
try {
...
} catch (Exception e) {
...
} finally {
...
}
} finally {
try {
...
} catch (Exception e) {
...
} finally {
...
}
}
}
}
Ну что же, давайте исследуем как это работает.
Вложенный try-catch-finally без исключения
public class App {
public static void main(String[] args) {
try {
System.err.print(" 0");
try {
System.err.print(" 1");
// НИЧЕГО
System.err.print(" 2");
} catch (RuntimeException e) {
System.err.print(" 3"); // НЕ заходим - нет исключения
} finally {
System.err.print(" 4"); // заходим всегда
}
System.err.print(" 5"); // заходим - выполнение в норме
} catch (Exception e) {
System.err.print(" 6"); // НЕ заходим - нет исключения
} finally {
System.err.print(" 7"); // заходим всегда
}
System.err.print(" 8"); // заходим - выполнение в норме
}
}
>> 0 1 2 4 5 7 8
Мы НЕ заходим в обе catch-секции (нет исключения), заходим в обе finally-секции и выполняем обе строки ПОСЛЕ finally.
Вложенный try-catch-finally с исключением, которое ПЕРЕХВАТИТ ВНУТРЕННИЙ catch
public class App {
public static void main(String[] args) {
try {
System.err.print(" 0");
try {
System.err.print(" 1");
if (true) {throw new RuntimeException();}
System.err.print(" 2");
} catch (RuntimeException e) {
System.err.print(" 3"); // ЗАХОДИМ - есть исключение
} finally {
System.err.print(" 4"); // заходим всегда
}
System.err.print(" 5"); // заходим - выполнение УЖЕ в норме
} catch (Exception e) {
System.err.print(" 6"); // не заходим - нет исключения, УЖЕ перехвачено
} finally {
System.err.print(" 7"); // заходим всегда
}
System.err.print(" 8"); // заходим - выполнение УЖЕ в норме
}
}
>> 0 1 3 4 5 7 8
Мы заходим в ПЕРВУЮ catch-секцию (печатаем «3»), но НЕ заходим во ВТОРУЮ catch-секцию (НЕ печатаем «6», так как исключение УЖЕ перехвачено первым catch), заходим в обе finally-секции (печатаем «4» и «7»), в обоих случаях выполняем код после finally (печатаем «5»и «8», так как исключение остановлено еще первым catch).
Вложенный try-catch-finally с исключением, которое ПЕРЕХВАТИТ ВНЕШНИЙ catch
public class App {
public static void main(String[] args) {
try {
System.err.print(" 0");
try {
System.err.print(" 1");
if (true) {throw new Exception();}
System.err.print(" 2");
} catch (RuntimeException e) {
System.err.print(" 3"); // НЕ заходим - есть исключение, но НЕПОДХОДЯЩЕГО ТИПА
} finally {
System.err.print(" 4"); // заходим всегда
}
System.err.print(" 5"); // не заходим - выполнение НЕ в норме
} catch (Exception e) {
System.err.print(" 6"); // ЗАХОДИМ - есть подходящее исключение
} finally {
System.err.print(" 7"); // заходим всегда
}
System.err.print(" 8"); // заходим - выполнение УЖЕ в норме
}
}
>> 0 1 4 6 7 8
Мы НЕ заходим в ПЕРВУЮ catch-секцию (не печатаем «3»), но заходим в ВТОРУЮ catch-секцию (печатаем «6»), заходим в обе finally-секции (печатаем «4» и «7»), в ПЕРВОМ случае НЕ выполняем код ПОСЛЕ finally (не печатаем «5», так как исключение НЕ остановлено), во ВТОРОМ случае выполняем код после finally (печатаем «8», так как исключение остановлено).
Вложенный try-catch-finally с исключением, которое НИКТО НЕ ПЕРЕХВАТИТ
public class App {
public static void main(String[] args) {
try {
System.err.print(" 0");
try {
System.err.print(" 1");
if (true) {throw new Error();}
System.err.print(" 2");
} catch (RuntimeException e) {
System.err.print(" 3"); // НЕ заходим - есть исключение, но НЕПОДХОДЯЩЕГО ТИПА
} finally {
System.err.print(" 4"); // заходим всегда
}
System.err.print(" 5"); // НЕ заходим - выполнение НЕ в норме
} catch (Exception e) {
System.err.print(" 6"); // не заходим - есть исключение, но НЕПОДХОДЯЩЕГО ТИПА
} finally {
System.err.print(" 7"); // заходим всегда
}
System.err.print(" 8"); // не заходим - выполнение НЕ в норме
}
}
>> 0 1 4 7
>> RUNTIME EXCEPTION: Exception in thread "main" java.lang.Error
Мы НЕ заходим в ОБЕ catch-секции (не печатаем «3» и «6»), заходим в обе finally-секции (печатаем «4» и «7») и в обоих случаях НЕ выполняем код ПОСЛЕ finally (не печатаем «5» и «8», так как исключение НЕ остановлено), выполнение метода прерывается по исключению.
Контакты
Я занимаюсь онлайн обучением Java (вот курсы программирования) и публикую часть учебных материалов в рамках переработки курса Java Core. Видеозаписи лекций в аудитории Вы можете увидеть на youtube-канале, возможно, видео канала лучше систематизировано в этой статье.
Мой метод обучения состоит в том, что я
- показываю различные варианты применения
- строю усложняющуюся последовательность примеров по каждому варианту
- объясняю логику двигавшую авторами (по мере возможности)
- даю большое количество тестов (50-100) всесторонне проверяющее понимание и демонстрирующих различные комбинации
- даю лабораторные для самостоятельной работы
Данная статье следует пунктам #1 (различные варианты) и #2(последовательность примеров по каждому варианту).
skype: GolovachCourses
email: GolovachCourses@gmail.com
#База знаний
- 24 фев 2021
-
13
Разбираемся, что такое исключения, зачем они нужны и как с ними работать.
vlada_maestro / shutterstock
Хлебом не корми — дай кому-нибудь про Java рассказать.
Из этой статьи вы узнаете:
- что такое исключения (Exceptions);
- как они возникают и чем отличаются от ошибок (Errors);
- зачем нужна конструкция try-catch;
- как разобраться в полученном исключении
- и как вызвать исключение самому.
Код вашей программы исправно компилируется и запускается, только вот вместо желанного результата вы видите непонятный текст. Строчки его будто кричат на вас, аж побагровели.
За примером далеко ходить не надо: сделаем то, что нам запрещали ещё в школе, — поделим на ноль.
public static void main(String[] args) {
hereWillBeTrouble(42, 0);
}
public static void hereWillBeTrouble(int a, int b) {
int oops = a / b;
System.out.println(oops);
}
А получим вот что:
Это и есть исключение.
«Исключение» — сокращение от слов «исключительный случай». Это ситуация, в которой программа не может продолжить работу или её работа становится бессмысленной. Причём речь не только о нештатных ситуациях — исключения бывают и намеренными, такие разработчик вызывает сам.
Это интересно. Исключения в Java появились уже в первой версии языка. А вот в языках, где их нет, вместо них возвращают коды ошибок.
У всех классов исключений есть общий класс-предок Throwable, от него наследуются классы Error и Exception, базовые для всех прочих.
Error — это критические условия, в которых работа программы должна быть завершена. Например, когда при выполнении программы закончилась память, произошёл сбой в системе или виртуальной машине. Не будем задерживаться на этой ветке, поскольку документация Java говорит:
Error is the superclass of all the exceptions from which ordinary programs are not ordinarily expected to recover.
Что в переводе означает: ошибки (Error) — это такие исключительные ситуации, в которых восстанавливать работу программы не предполагается.
То есть это проблемы, которые нельзя (недопустимо) исправлять на ходу. Всё, что нам остаётся, — извиниться перед пользователем и впредь писать программы, где возникнет меньше подобных ситуаций. Например, не допускать такой глубокой рекурсии, как в коде ниже:
static void notGood() {
System.out.println("Только не снова!");
notGood();
}
При работе этого метода у нас возникнет ошибка: Exception in thread «main» java.lang.StackOverflowError — стек вызовов переполнился, так как мы не указали условие выхода из рекурсии.
А теперь об Exception. Эти исключительные ситуации возникают, если разработчик допустил невыполнимую операцию, не предусмотрел особые случаи в бизнес-логике программы (или сообщает о них с помощью исключений).
1. Невыполнимая операция
Мир не рухнул, как в случае с Error, просто Java не знает, что делать дальше. Как раз из этого разряда деление на ноль в начале статьи: и правда, какое значение тогда присвоить переменной oops?
Убедитесь сами, что исключение класса ArithmeticException наследуется как раз от Exception.
Стоит запомнить. В IntelliJ IDEA, чтобы увидеть положение класса в иерархии, выберите его и нажмите Ctrl + H (или на пункт Type Hierarchy в меню Navigate).
Другая частая ситуация — обращение к несуществующему элементу массива. Например, у нас в нём десять элементов, а мы пытаемся обратиться к одиннадцатому.
2. Особый случай в бизнес-логике программы
Классика. Программируем задачу о перевозке волка, козы и капусты через реку: в лодке может быть только два пассажира, но волка с козой и козу с капустой нельзя оставлять на берегу вместе. Это и есть особый случай в бизнес-логике, который нельзя нарушать.
Или пользователь вводит дату начала некоторого периода и дату его окончания. Вторая дата не может быть раньше первой.
Или, допустим, у нас есть метод, который читает файл. Сам метод написан верно. Пользователь передал в него корректный путь. Только вот у этого работника нет права читать этот файл (его роль и права обусловлены предметной областью). Что же тогда методу возвращать? Вернуть-то нечего, ведь метод не отработал. Самое очевидное решение — выдать исключение.
В дерево исключений мы ещё углубимся, а сейчас посмотрим, что и как с ними делают.
Простейший вариант — ничего; возникает исключение — программа просто прекращает работать.
Чтобы убедиться в этом, выполним код:
public static void main(String[] args) {
hereWillBeTrouble(42, 0);
}
public static void hereWillBeTrouble(int a, int b) {
System.out.println("Всё, что было до...");
int oops = a / b;
System.out.println(oops);
System.out.println("Всё, что будет после...");
}
Так и есть: до деления на ноль код выполнялся, а после — нет.
Это интересно: когда возникает исключение, программисты выдают что-то вроде «код [вы]бросил исключение» или «код кинул исключение». А глагол таков потому, что все исключения — наследники класса Throwable, что значит «бросаемый» / «который можно бросить».
Второе, что можно делать с исключениями, — это их обрабатывать.
Для этого нужно заключить кусок кода, который может вызвать исключение, в конструкцию try-catch.
Как это работает: если в блоке try возникает исключение, которое указано в блоке catch, то исполнение блока try прервётся и выполнится код из блока catch.
Например:
public static void main(String[] args) {
hereWillBeTrouble();
}
private static void hereWillBeTrouble(int a, int b) {
int oops;
try {
System.out.println("Всё, что было до...");
oops = a / b;
System.out.println(oops);
System.out.println("Всё, что будет после...");
} catch (ArithmeticException e) {
System.out.println("Говорили же не делить на ноль!");
oops = 0;
}
System.out.println("Метод отработал");
}
Разберём этот код.
Если блок try кинет исключение ArithmeticException, то управление перехватит блок catch, который выведет строку «Говорили же не делить на ноль!», а значение oops станет равным 0.
После этого программа продолжит работать как ни в чём не бывало: выполнится код после блока try-catch, который сообщит: «Метод отработал».
Проверьте сами: запустите код выше. Вызовите метод hereWillBeTrouble с любыми значениями аргументов кроме нулевого b. Если в блоке try не возникнет исключений, то его код выполнится целиком, а в блок catch мы даже не попадём.
Есть ещё и третий вариант — пробросить исключение наверх. Но об этом в следующей статье.
Вернёмся к первой картинке. Посмотрим, что нам сказала Java, когда произошло исключение:
Начинаем разбирать сверху вниз:
— это указание на поток, в котором произошло исключение. В нашей простой однопоточной программе это поток main.
— какое исключение брошено. У нас это ArithmeticException. А java.lang.ArithmeticException — полное название класса вместе с пакетом, в котором он размещается.
— весточка, которую принесло исключение. Дело в том, что одно и то же исключение нередко возникает по разным причинам. И тут мы видим стандартное пояснение «/ by zero» — из-за деления на ноль.
— это самое интересное: стектрейс.
Стектрейс (Stack trace) — это упорядоченный список методов, сквозь которые исключение пронырнуло.
У нас оно возникло в методе hereWillBeTrouble на 8-й строке в классе Main (номер строки и класс указаны в скобках синим). А этот метод, в свою очередь, вызван методом main на 3-й строке класса Main.
Стектрейсы могут быть довольно длинными — из десятков методов, которые вызывают друг друга по цепочке. И они здорово помогают расследовать неожиданно кинутое исключение.
Советую закреплять теорию на практике. Поэтому вернитесь в блок про Error и вызовите метод notGood — увидите любопытный стектрейс.
Всё это время мы имели дело с исключением, которое бросает Java-машина — при делении на ноль. Но как вызвать исключение самим?
Раз исключение — это объект класса, то программисту всего-то и нужно, что создать объект с нужным классом исключения и бросить его с помощью оператора throw.
public static void main(String[] args) {
hereWillBeTrouble(42, 0);
}
private static void hereWillBeTrouble(int a, int b) {
if (b == 0) {
throw new ArithmeticException("ты опять делишь на ноль?");
}
int oops = a / b;
System.out.println(oops);
}
При создании большинства исключений первым параметром в конструктор можно передать сообщение — мы как раз сделали так выше.
А получим мы то же самое, что и в самом первом примере, только вместо стандартной фразы «/by zero» теперь выдаётся наш вопрос-пояснение «ты опять делишь на ноль?»:
В следующей статье мы углубимся в иерархию исключений Java, узнаем про их разделение на checked и unchecked, а также о том, что ещё интересного можно с ними делать.
Учись бесплатно:
вебинары по программированию, маркетингу и дизайну.
Участвовать
Школа дронов для всех
Учим программировать беспилотники и управлять ими.
Узнать больше
As developers, we would like our users to interact with applications that run smoothly and without issues. We want the libraries that we create to be widely adopted and successful. All of that will not happen without the code that handles errors.
Java exception handling is often a significant part of the application code. You might use conditionals to handle cases where you expect a certain state and want to avoid erroneous execution – for example, division by zero. However, there are cases where conditions are not known or are well hidden because of third party code. In other cases, code is designed to create an exception and throw it up the stack to allow for the graceful handling of a Java error at a higher level.
If all this is new to you, this tutorial will help you understand what Java exceptions are, how to handle them and the best practices you should follow to maintain the natural flow of the application.
What Is an Exception in Java?
An Exception is an event that causes your normal Java application flow to be disrupted. Exceptions can be caused by using a reference that is not yet initialized, dividing by zero, going beyond the length of an array, or even JVM not being able to assign objects on the heap.
In Java, an exception is an Object that wraps the error that caused it and includes information like:
- The type of error that caused the exception with the information about it.
- The stack trace of the method calls.
- Additional custom information that is related to the error.
Various Java libraries throw exceptions when they hit a state of execution that shouldn’t happen – from the standard Java SDK to the enormous amounts of open source code that is available as a third-party library.
Exceptions can be created automatically by the JVM that is running our code or explicitly our code itself. We can extend the classes that are responsible for exceptions and create our own, specific Java exceptions that handle unexpected situations. But keep in mind that throwing an exception doesn’t come for free. It is expensive. The larger the call stack the more expensive the exception.
Exception handling in Java is a mechanism to process, catch and throw Java errors that signal an abnormal state of the program so that the execution of the business code can continue uninterrupted.
Why Handle Java Exceptions?
Using Java exceptions is very handy; they let you separate the business logic from the application code for handling errors. However, exceptions are neither free nor cheap. Throwing an exception requires the JVM to perform operations like gathering the full stack trace of the method calls and passing it to the method that is responsible for handling the exception. In other words, it requires additional resources compared to a simple conditional.
No matter how expensive the exceptions are, they are invaluable for troubleshooting issues. Correlating exceptions with other data like JVM metrics and various application logs can help with resolving your problems fast and in a very efficient manner.
Exception Class Hierarchy
Java is an object-oriented language, and thus, every class will extend the java.lang.Object. The same goes for the Throwable class, which is the base class for the errors and exceptions in Java. The following picture illustrates the class hierarchy of the Throwable class and its most common subclasses:
The Difference Between a Java Exception and Error
Before going into details about the Exception class, we should ask one fundamental question: What is the difference between an Error and an Exception in Java?
To answer the question, let’s look at Javadocs and start from the Throwable class. The Throwable class is the mother of all errors–the superclass of all errors and exceptions that your Java code can produce. Only objects that are instances of the Throwable class or any of its subclasses can be thrown by the code running inside the JVM or can be declared in the methods throw clause. There are two main implementations of the Throwable class.
A Java Error is a subclass of Throwable that represents a serious problem that a reasonable application should not try to catch. The method does not have to declare an Error or any of its subclasses in its throws clause for it to be thrown during the execution of a method. The most common subclasses of the Error class are Java OutOfMemoryError and StackOverflowError classes. The first one represents JVM not being able to create a new object; we discussed potential causes in our article about the JVM garbage collector. The second error represents an issue when the application recurses too deeply.
The Java Exception and its subclasses, on the other hand, represent situations that an application should catch and try to handle. There are lots of implementations of the Exception class that represent situations that your application can gracefully handle. The FileNotFoundException, SocketException, or NullPointerException are just a few examples that you’ve probably come across when writing Java applications.
Types of Java Exceptions
There are multiple implementations of the Exception class in Java. They come from the Java Development Kit itself, but also from various libraries and applications that you might be using when writing your own code. We will not discuss every Exception subclass that you can encounter, but there are two main types that you should be aware of to understand how exception handling works in Java–the checked and unchecked, aka runtime exceptions.
Checked Exceptions
The Java checked exceptions are the ones that implement the Exception class and not the RuntimeException. They are called checked exceptions because the compiler verifies them during the compile-time and refuses to compile the code if such exceptions are not handled or declared. Instead, the compiler will notify you to handle these exceptions. For example, the FileNotFoundException is an example of such an exception.
In order for a method or constructor to throw a checked exception it needs to be explicitly declared:
public CheckedExceptions() throws FileNotFoundException {
throw new FileNotFoundException("File not found");
}
public void throwsExample() throws FileNotFoundException {
throw new FileNotFoundException("File not found");
}
You can see that in both cases we explicitly have the throws clause mentioning the FileNotFoundException that can be thrown by the execution of the constructor of the throwsExample method. Such code will be successfully compiled and can be executed.
On the other hand, the following code will not compile:
public void wrongThrowsExample() {
throw new FileNotFoundException("File not found");
}
The reason for the compiler not wanting to compile the above code will be raising the checked exception and not processing it. We need to either include the throws clause or handle the Java exception in the try/catch/finally block. If we were to try to compile the above code as is the following error would be returned by the compiler:
/src/main/java/com/sematext/blog/java/CheckedExceptions.java:18: error: unreported exception FileNotFoundException; must be caught or declared to be thrown
throw new FileNotFoundException("File not found");
^
Unchecked Exceptions / Runtime Exceptions
The unchecked exceptions are exceptions that the Java compiler does not require us to handle. The unchecked exceptions in Java are the ones that implement the RuntimeException class. Those exceptions can be thrown during the normal operation of the Java Virtual Machine. Unchecked exceptions do not need to be declared in the method throws clause in order to be thrown. For example, this block of code will compile and run without issues:
public class UncheckedExceptions {
public static void main(String[] args) {
UncheckedExceptions ue = new UncheckedExceptions();
ue.run();
}
public void run() {
throwRuntimeException();
}
public void throwRuntimeException() {
throw new NullPointerException("Null pointer");
}
}
We create an UncheckedExceptions class instance and run the run method. The run method calls the throwRuntimeException method which creates a new NullPointerException. Because the NullPointerException is a subclass of the RuntimeException we don’t need to declare it in the throws clause.
The code compiles and propagates the exception up to the main method. We can see that in the output when the code is run:
Exception in thread "main" java.lang.NullPointerException: Null pointer
at com.sematext.blog.java.UncheckedExceptions.throwRuntimeException(UncheckedExceptions.java:14)
at com.sematext.blog.java.UncheckedExceptions.run(UncheckedExceptions.java:10)
at com.sematext.blog.java.UncheckedExceptions.main(UncheckedExceptions.java:6)
This is exactly what we expected.
The most common subclasses of the Java RuntimeException that you probably saw already are ClassCastException, ConcurrentModificationException, IllegalArgumentException, or everyone’s favorite, NullPointerException.
Let’s now look at how we throw exceptions in Java.
How to Handle Exceptions in Java: Code Examples
Handling exceptions in Java is a game of using five keywords that combined give us the possibility of handling errors – the try, catch, finally, throw, and throws.
The first one – try is used to specify the block of code that can throw an exception:
try {
File file = openNewFileThatMayNotExists(location);
// process the file
}
The try block must be followed by the catch or finally blocks. The first one mentioned can be used to catch and process exceptions thrown in the try block:
try {
...
} catch (IOException ioe) {
// handle missing file
}
The finally block can be used to handle the code that needs to be executed regardless of whether the exception happened or not.
The throw keyword is used to create a new Exception instance and the throws keyword is used to declare what kind of exceptions can be expected when executing a method.
When handling exceptions in Java, we don’t want to just throw the created exception to the top of the call stack, for example, to the main method. That would mean that each and every exception that is thrown would crash the application and this is not what should happen. Instead, we want to handle Java exceptions, at least the ones that we can deal with, and either help fixing the problem or fail gracefully.
Java gives us several ways to handle exceptions.
Throwing Exceptions
An Exception in Java can be handled by using the throw keyword and creating a new Exception or re-throwing an already created exception. For example, the following very naive and simple method creates an instance of the File class and checks if the file exists. If the file doesn’t exist the method throws a new IOException:
public File openFile(String path) throws IOException {
File file = new File(path);
if (!file.exists()) {
throw new IOException(String.format("File %s doesn't exist", path));
}
// continue execution of the business logic
return file;
}
You can also re-throw a Java exception that was thrown inside the method you are executing. This can be done by the try-catch block:
public class RethrowException {
public static void main(String[] args) throws IOException {
RethrowException exec = new RethrowException();
exec.run();
}
public void run() throws IOException {
try {
methodThrowingIOE();
} catch (IOException ioe) {
// do something about the exception
throw ioe;
}
}
public void methodThrowingIOE() throws IOException {
throw new IOException();
}
}
You can see that the run method re-throws the IOException that is created in the methodThrowingIOE. If you plan on doing some processing of the exception, you can catch it as in the above example and throw it further. However, keep in mind that in most cases, this is not a good practice. You shouldn’t catch the exception, process it, and push it up the execution stack. If you can’t process it, it is usually better to pack it into a more specialized Exception class, so that a dedicated error processing code can take care of it. You can also just decide that you can’t process it and just throw it:
public class RethrowException {
public static void main(String[] args) throws IOException {
RethrowException exec = new RethrowException();
exec.run();
}
public void run() throws IOException {
try {
methodThrowingIOE();
} catch (IOException ioe) {
throw ioe;
}
}
public void methodThrowingIOE() throws IOException {
throw new IOException();
}
}
There are additional cases, but we will discuss them when talking about how to catch exceptions in Java.
Try-Catch Block
The simplest and most basic way to handle exceptions is to use the try – catch block. The code that can throw an exception is put into the try block and the code that should handle it is in the catch block. The exception can be either checked or unchecked. In the first case, the compiler will tell you which kind of exceptions need to be caught or defined in the method throws clause for the code to compile. In the case of unchecked exceptions, we are not obligated to catch them, but it may be a good idea – at least in some cases. For example, there is a DOMException or DateTimeException that indicate issues that you can gracefully handle.
To handle the exception, the code that might generate an exception should be placed in the try block which should be followed by the catch block. For example, let’s look at the code of the following openFileReader method:
public Reader openFileReader(String filePath) {
try {
return new FileReader(filePath);
} catch (FileNotFoundException ffe) {
// tell the user that the file was not found
}
return null;
}
The method tries to create a FileReader class instance. The constructor of that class can throw a checked FileNotFoundException if the file provided as the argument doesn’t exist. We could just include the FileNotFoundException in the throws clause of our openFileReader method or catch it in the catch section just like we did. In the catch section, we can do whatever we need to get a new file location, create a new file, and so on.
If we would like to just throw it further up the call stack the code could be further simplified:
public Reader openFileReaderWithThrows(String filePath) throws FileNotFoundException {
return new FileReader(filePath);
}
This passes the responsibility of handling the FIleNotFoundException to the code that calls it.
Multiple Catch Block
We are not limited to a single catch block in the try-catch block. We can have multiple try-catch blocks that allow you to handle each exception differently, would you need that. Let’s say that we have a method that lists more than a single Java exception in its throws clause, like this:
public void readAndParse(String file) throws FileNotFoundException, ParseException {
// some business code
}
In order to compile and run this we need multiple catch blocks to handle each of the listed Java exceptions:
public void run(String file) {
try {
readAndParse(file);
} catch (FileNotFoundException ex) {
// do something when file is not found
} catch (ParseException ex) {
// do something if the parsing fails
}
}
Such code organization can be used when dealing with multiple Java exceptions that need to be handled differently. Hypothetically, the above code could ask for a new file location when the FileNotFoundException happens and inform the user of the issues with parsing when the ParseException happens.
There is one more thing we should mention when it comes to handle exceptons using multiple catch blocks. You need to remember that the order of the catch blocks matters. If you have a more specialized Java exception in the catch block after the more general exception the more specialized catch block will never be executed. Let’s look at the following example:
public void runTwo(String file) {
try {
readAndParse(file);
} catch (Exception ex) {
// this block will catch all exceptions
} catch (ParseException ex) {
// this block will not be executed
}
}
Because the first catch block catches the Java Exception the catch block with the ParseException will never be executed. That’s because the ParseException is a subclass of the Exception.
Catching Multiple Exceptions
To handle multiple Java exceptions with the same logic, you can list them all inside a single catch block. Let’s redo the above example with the FileNotFoundException and the ParseException to use a single catch block:
public void runSingleCatch(String file) {
try {
readAndParse(file);
} catch (FileNotFoundException | ParseException ex) {
// do something when file is not found
}
}
You can see how easy it is–you can connect multiple Java exceptions together using the | character. If any of these exceptions is thrown in the try block the execution will continue inside the catch block.
The Finally Block
In addition to try and the catch blocks, there is one additional section that may come in handy when handling exceptions in Java–the finally block. The finally block is the last section in your try-catch-finally expression and will always get executed–either after the try or after the catch. It will be executed even if you use the return statement in the try block, which by the way, you shouldn’t do.
Let’s look at the following example:
public void exampleOne() {
FileReader reader = null;
try {
reader = new FileReader("/tmp/somefile");
// do some processing
} catch (FileNotFoundException ex) {
// do something
} finally {
if (reader != null) {
try {
reader.close();
} catch (IOException ex) {
// do something
}
}
}
}
You can see the finally block. Keep in mind that you can have at most one finally block present. The way this code will be executed is as follows:
- The JVM will execute the try section first and will try to create the FileReader instance.
- If the /tmp/somefile is present and readable the try block execution will continue.
- If the /tmp/somefile is not present or is not readable the FileNotFoundException will be raised and the execution of the code will go to the catch block.
- After 2) or 3) the finally block will be executed and will try to close the FileReader instance if it is present.
The finally section will be executed even if we modify the try block and include the return statement. The following code does exactly the same as the one above despite having the return statement at the end of the try block:
public void exampleOne() {
FileReader reader = null;
try {
reader = new FileReader("/tmp/somefile");
// do something
return;
} catch (FileNotFoundException ex) {
// do something
} finally {
if (reader != null) {
try {
reader.close();
} catch (IOException ex) {
// do something
}
}
}
}
So, why and when should you use the finally block to handle exceptions in Java? Well, it is a perfect candidate for cleaning up resources, like closing objects, calculating metrics, including Java logs about operation completion, and so on.
The Try-With-Resources Block
The last thing when it comes to handling exceptions in Java is the try-with-resources block. The idea behind that Java language structure is opening resources in the try section that will be automatically closed at the end of the statement. That means that instead of including the finally block we can just open the resources that we need in the try section and rely on the Java Virtual Machine to deal with the closing of the resource.
For the class to be usable in the try-with-resource block it needs to implement the java.lang.AutoCloseable, which includes every class implementing the java.io.Closeable interface. Keep that in mind.
An example method that reads a file using the FileReader class which uses the try-with-resources might look as follows:
public void readFile(String filePath) {
try (FileReader reader = new FileReader(filePath)) {
// do something
} catch (FileNotFoundException ex) {
// do something when file is not found
} catch (IOException ex) {
// do something when issues during reader close happens
}
}
Of course, we are not limited to a single resource and we can have multiple of them, for example:
public void readFiles(String filePathOne, String filePathTwo) {
try (
FileReader readerOne = new FileReader(filePathOne);
FileReader readerTwo = new FileReader(filePathTwo);
) {
// do something
} catch (FileNotFoundException ex) {
// do something when file is not found
} catch (IOException ex) {
// do something when issues during reader close happens
}
}
One thing that you have to remember is that you need to process the Java exceptions that happen during resources closing in the catch section of the try-catch-finally block. That’s why in the above examples, we’ve included the IOException in addition to the FileNotFoundException. The IOException may be thrown during FileReader closing and we need to process it.
Catching User-Defined Exceptions
The Throwable and Exception are Java classes and so you can easily extend them and create your own exceptions. Depending on if you need a checked or unchecked exception you can either extend the Exception or the RuntimeException class. To give you a very simple example on how such code might look like, have a look at the following fragment:
public class OwnExceptionExample {
public void doSomething() throws MyOwnException {
// code with very important logic
throw new MyOwnException("My Own Exception!");
}
class MyOwnException extends Exception {
public MyOwnException(String message) {
super(message);
}
}
}
In the above trivial example we have a new Java Exception implementation called MyOwnException with a constructor that takes a single argument – a message. It is an internal class, but usually you would just move it to an appropriate package and start using it in your application code.
How to Catch Specific Java Exceptions
Catching specific Java exceptions is not very different from handling a general exception. Let’s look at the code examples. Catching exceptions that implement the Exception class is as simple as having a code similar to the following one:
try {
// code that can result in exception throwing
} catch (Exception ex) {
// handle exception
}
The catch block in the above example would run for every object implementing the Exception class. These include IOException, EOFException, FileNotFoundException, or the NullPointerException. But sometimes we may want to have different behavior depending on the exception that was thrown. You may want different behavior for the IOException and different for the FileNotFoundException. This can be achieved by having multiple catch blocks:
try {
// code that can result in exception throwing
} catch (FileNotFoundException ex) {
// handle exception
} catch (IOException ex) {
// handle exception
}
There is one thing to remember though. The first catch clause that will match the exception class will be executed. The FileNotFoundException is a subclass of the IOException. That’s why I specified the FileNotFoundException as the first one. If I would do the opposite, the block with the IOException handling would catch all IOException instances and their subclasses. Something worth remembering.
Finally, we’ve mentioned that before, but I wanted to repeat myself here – if you would like to handle numerous exceptions with the same code you can do that by combining them in a single catch block:
try {
// code that can result in exception throwing
} catch (FileNotFoundException | EOFException ex) {
// handle exception
} catch (IOException ex) {
// handle exception
}
That way you don’t have to duplicate the code.
Java Exception Handling Best Practices
There are a lot of best practices when it comes to handling exceptions in the Java Virtual Machine world, but I find a few of them useful and important.
Keep Exceptions Use to a Minimum
Every time you throw an Exception it needs to be handled by the JVM. Throwing an exception doesn’t cost much, but for example, getting the stack trace for the exception is noticeable, especially when you deal with a large number of concurrent requests and get the stack trace for every exception.
What I will say is not true for every situation and for sure makes the code a bit uglier, but if you want to squeeze every bit of performance from your code, try to avoid Java exceptions when a simple comparison is enough. Look at the following method:
public int divide(int dividend, int divisor) {
try {
return dividend / divisor;
} catch (ArithmeticException ex) {
LOG.error("Error while division, stack trace:", ex.getStackTrace());
}
return -1;
}
It tries to divide two numbers and catches the ArithmeticException in case of a Java error. What kind of error can happen here? Well, division by zero is the perfect example. If the divisor argument is 0 the code will throw an exception, catch it to avoid failure in the code and continue returning -1. This is not the perfect way to go since throwing a Java exception has a performance penalty – we talk about it later in the blog post. In such cases, you should check the divisor argument and allow the division only if it is not equal to 0, just like this:
public int divide(int dividend, int divisor) {
if (divisor != 0) {
return 10 / divisor;
}
return -1;
}
The performance of throwing an exception is not high, but parts of the error handling code may be expensive – for example stack trace retrieval. Keep that in mind when writing your code that handles Java exceptions and situations that should not be allowed.
Always Handle Exceptions, Don’t Ignore Them
Always handle the Java Exception, unless you don’t care about one. But if you think that you should ignore one, think twice. The methods that you call throw exceptions for a reason and you may want to process them to avoid problematic situations.
Process the exceptions, log them, or just print them to the console. Avoid doing things you can see in the following code:
try {
FileReader reader = new FileReader(filePath);
// some business code
} catch (FileNotFoundException ex) {}
As you can see in the code above the FileNotFoundException is hidden and we don’t have any idea that the creation of the FileReader failed. Of course, the code that runs after the creation of the FileReader would probably fail if it were to operate on that. Now imagine that you are catching Java exceptions like this:
try {
FileReader reader = new FileReader(filePath);
// some business code
} catch (Exception ex) {}
You would catch lots of Java exceptions and completely ignore them all. The least you would like to do is fail and log the information so that you can easily find the problem when doing log analysis or setting up an alert in your log centralization solution. Of course, you may want to process the exception, maybe do some interaction with external systems or the user itself, but for sure not hide the problem.
If you really don’t want to handle an exception in Java you can just print it to the log or error stream, for example:
try {
FileReader reader = new FileReader(filePath);
// some business code
} catch (Exception ex) {
ex.printStackTrace();
}
Or even better, if you are using a centralized logging solution just do the following to store the error log there:
try {
FileReader reader = new FileReader(filePath);
// some business code
} catch (Exception ex) {
LOG.error("Error during FileReader creation", ex);
}
Use Descriptive Messages When Throwing Exceptions
When using exceptions, think about the person who will be looking at the logs or will be troubleshooting your application. Think about what kind of information will be needed to quickly and efficiently find the root cause of the problem – Java exceptions in our case.
When throwing an exception you can use code like this:
throw new FileNotFoundException(“file not found”);
Or code that looks like this:
throw new FileNotFoundException(String.format(“File %s not found in directory %s”, file, directory));
The first one will just say that some mystery file was not found. The person that will try to diagnose and fix the problem will not know which and where the file is expected to be. The second example explicitly mentions which file is expected and where – and it is exactly what you should do when throwing exceptions.
Never Use Return Statement in the Finally Block
The finally block is the place in which you can execute code regardless if the exception happened or not – for example close the opened resources to avoid leaks. The next thing you should avoid is using the return statement in the finally block of your code. Have a look at the following code fragment:
public class ReturnInFinally {
public static void main(String[] args) {
ReturnInFinally app = new ReturnInFinally();
app.example();
System.out.println("Ended without error");
}
public void example() {
try {
throw new NullPointerException();
} finally {
return;
}
}
}
If you were to run it, it would end up printing the Ended without error to the console. But we did throw the NullPointerException, didn’t we? Yes, but that would be hidden because of our finally block. We didn’t catch the exception and according to Java language Exception handling specification, the exception would just be discarded. We don’t want something like that to happen, because that would mean that we are hiding issues in the code and its execution.
Never Use Throw Statement in the Finally Block
A very similar situation to the one above is when you try to throw a new Java Exception in the finally block. Again, the code speaks louder than a thousand words, so let’s have a look at the following example:
public class ThrowInFinally {
public static void main(String[] args) {
ThrowInFinally app = new ThrowInFinally();
app.example();
}
public void example() {
try {
throw new RuntimeException("Exception in try");
} finally {
throw new RuntimeException("Exception in finally");
}
}
}
If you were to execute the above code the sentence that will be printed in the error console would be the following:
Exception in thread "main" java.lang.RuntimeException: Exception in finally at com.sematext.blog.java.ThrowInFinally.example(ThrowInFinally.java:13) at com.sematext.blog.java.ThrowInFinally.main(ThrowInFinally.java:6)
Yes, it is true. The Java RuntimeException that was thrown in the try block will be hidden and the one that was thrown in the finally block will take its place. It may not seem big, but have a look at the code like this:
public void example() throws Exception {
FileReader reader = null;
try {
reader = new FileReader("/tmp/somefile");
} finally {
reader.close();
}
}
Now think about the execution of the code and what happens in a case where the file specified by the filePath is not available. First, the FileReader constructor would throw a FileNotFoundException and the execution would jump to the finally block. Once it gets there it would try to call the close method on a reference that is null. That means that the NullPointerException would be thrown here and the whole example method would throw it. So practically, the FileNotFoundException would be hidden and thus the real problem would not be easily visible that well.
Performance Side Effects of Using and Handling Exceptions in Java
We’ve mentioned that using exceptions in Java doesn’t come for free. Throwing an exception requires the JVM to fill up the whole call trace, list each method that comes with it, and pass it further to the code that will finally catch and handle the Java exception. That’s why you shouldn’t use exceptions unless it is really necessary.
Let’s look at a very simple test. We will run two classes–one will do the division by zero and catch the exception that is caused by that operation. The other code will check if the divisor is zero before throwing the exception. The mentioned code is encapsulated in a method.
The code that uses an exception looks as follows:
public int divide(int dividend, int divisor) {
try {
return dividend / divisor;
} catch (Exception ex) {
// handle exception
}
return -1;
}
The code that does a simple check using a conditional looks as follows:
public int divide(int dividend, int divisor) {
if (divisor != 0) {
return 10 / divisor;
}
return -1;
}
One million executions of the first method take 15 milliseconds, while one million executions of the second method take 5 milliseconds. So you can clearly see that there is a large difference in the execution time when running the code with exceptions and when using a simple conditional to check if the execution should be allowed. Of course, keep in mind that this comparison is very, very simple, and doesn’t reflect real-world scenarios, but it should give you an idea of what to expect when crafting your own code.
The test execution time will differ depending on the machine, but you can run it on your own if you would like by cloning this Github repository.
Troubleshooting Java Exceptions with Sematext
Handling exceptions properly in your Java code is important. Equally important is being able to use them for troubleshooting your Java applications. With Sematext Cloud you can find the most frequent errors and exceptions in your Java application logs, create custom dashboards for your team and set up real-time alerts and anomaly detection to notify you of issues that require your attention. Can you also correlate errors, exceptions, and other application logs with your application performance metrics? You can use Sematext not only for Java monitoring, but also to monitor Elasticsearch, Tomcat, Solr, Kafka, Nginx, your servers, processes, databases, even your packages, and the rest of your infrastructure. With service auto-discovery and monitoring everything is just a click away 🙂
Conclusion
Even though exceptions in Java are not free and have a performance penalty they are invaluable for handling errors in your applications. They help in decoupling the main business code from the error handling code making the whole code cleaner and easier to understand. Using exceptions wisely will make your code look good, be extensible, maintainable, and fun to work with. Use them following exception handling best practices and log everything they tell you into your centralized logging solution so that you can get the most value out of any thrown exception.
If you don’t know where to start looking for the perfect logging solution for you, we wrote in-depth comparisons of various log management tools, log analyzers, and cloud logging services available today to fund the one that fits your use case.
Содержание
- 1 Методы обработки ошибок
- 2 Исключения
- 3 Классификация исключений
- 3.1 Проверяемые исключения
- 3.2 Error
- 3.3 RuntimeException
- 4 Обработка исключений
- 4.1 try-catch-finally
- 4.2 Обработка исключений, вызвавших завершение потока
- 4.3 Информация об исключениях
- 5 Разработка исключений
- 6 Исключения в Java7
- 7 Примеры исключений
- 8 Гарантии безопасности
- 9 Источники
Методы обработки ошибок
1. Не обрабатывать.
2. Коды возврата. Основная идея — в случае ошибки возвращать специальное значение, которое не может быть корректным. Например, если в методе есть операция деления, то придется проверять делитель на равенство нулю. Также проверим корректность аргументов a и b:
Double f(Double a, Double b) {
if ((a == null) || (b == null)) {
return null;
}
//...
if (Math.abs(b) < EPS) {
return null;
} else {
return a / b;
}
}
При вызове метода необходимо проверить возвращаемое значение:
Double d = f(a, b); if (d != null) { //... } else { //... }
Минусом такого подхода является необходимость проверки возвращаемого значения каждый раз при вызове метода. Кроме того, не всегда возможно определить тип ошибки.
3.Использовать флаг ошибки: при возникновении ошибки устанавливать флаг в соответствующее значение:
boolean error; Double f(Double a, Double b) { if ((a == null) || (b == null)) { error = true; return null; } //... if (Math.abs(b) < EPS) { error = true; return b; } else { return a / b; } }
error = false; Double d = f(a, b); if (error) { //... } else { //... }
Минусы такого подхода аналогичны минусам использования кодов возврата.
4.Можно вызвать метод обработки ошибки и возвращать то, что вернет этот метод.
Double f(Double a, Double b) {
if ((a == null) || (b == null)) {
return nullPointer();
}
//...
if (Math.abs(b) < EPS) {
return divisionByZero();
} else {
return a / b;
}
}
Но в таком случае не всегда возможно проверить корректность результата вызова основного метода.
5.В случае ошибки просто закрыть программу.
if (Math.abs(b) < EPS) { System.exit(0); return this; }
Это приведет к потере данных, также невозможно понять, в каком месте возникла ошибка.
Исключения
В Java возможна обработка ошибок с помощью исключений:
Double f(Double a, Double b) {
if ((a == null) || (b == null)) {
throw new IllegalArgumentException("arguments of f() are null");
}
//...
return a / b;
}
Проверять b на равенство нулю уже нет необходимости, так как при делении на ноль метод бросит непроверяемое исключение ArithmeticException.
Исключения позволяют:
- разделить обработку ошибок и сам алгоритм;
- не загромождать код проверками возвращаемых значений;
- обрабатывать ошибки на верхних уровнях, если на текущем уровне не хватает данных для обработки. Например, при написании универсального метода чтения из файла невозможно заранее предусмотреть реакцию на ошибку, так как эта реакция зависит от использующей метод программы;
- классифицировать типы ошибок, обрабатывать похожие исключения одинаково, сопоставлять специфичным исключениям определенные обработчики.
Каждый раз, когда при выполнении программы происходит ошибка, создается объект-исключение, содержащий информацию об ошибке, включая её тип и состояние программы на момент возникновения ошибки.
После создания исключения среда выполнения пытается найти в стеке вызовов метод, который содержит код, обрабатывающий это исключение. Поиск начинается с метода, в котором произошла ошибка, и проходит через стек в обратном порядке вызова методов. Если не было найдено ни одного подходящего обработчика, выполнение программы завершается.
Таким образом, механизм обработки исключений содержит следующие операции:
- Создание объекта-исключения.
- Заполнение stack trace’а этого исключения.
- Stack unwinding (раскрутка стека) в поисках нужного обработчика.
Классификация исключений
Класс Java Throwable описывает все, что может быть брошено как исключение. Наследеники Throwable — Exception и Error — основные типы исключений. Также RuntimeException, унаследованный от Exception, является существенным классом.
Иерархия стандартных исключений
Проверяемые исключения
Наследники класса Exception (кроме наслеников RuntimeException) являются проверяемыми исключениями(checked exception). Как правило, это ошибки, возникшие по вине внешних обстоятельств или пользователя приложения – неправильно указали имя файла, например. Эти исключения должны обрабатываться в ходе работы программы, поэтому компилятор проверяет наличие обработчика или явного описания тех типов исключений, которые могут быть сгенерированы некоторым методом.
Все исключения, кроме классов Error и RuntimeException и их наследников, являются проверяемыми.
Error
Класс Error и его подклассы предназначены для системных ошибок. Свои собственные классы-наследники для Error писать (за очень редкими исключениями) не нужно. Как правило, это действительно фатальные ошибки, пытаться обработать которые довольно бессмысленно (например OutOfMemoryError).
RuntimeException
Эти исключения обычно возникают в результате ошибок программирования, такие как ошибки разработчика или неверное использование интерфейса приложения. Например, в случае выхода за границы массива метод бросит OutOfBoundsException. Такие ошибки могут быть в любом месте программы, поэтому компилятор не требует указывать runtime исключения в объявлении метода. Теоретически приложение может поймать это исключение, но разумнее исправить ошибку.
Обработка исключений
Чтобы сгенерировать исключение используется ключевое слово throw. Как и любой объект в Java, исключения создаются с помощью new.
if (t == null) { throw new NullPointerException("t = null"); }
Есть два стандартных конструктора для всех исключений: первый — конструктор по умолчанию, второй принимает строковый аргумент, поэтому можно поместить подходящую информацию в исключение.
Возможна ситуация, когда одно исключение становится причиной другого. Для этого существует механизм exception chaining. Практически у каждого класса исключения есть конструктор, принимающий в качестве параметра Throwable – причину исключительной ситуации. Если же такого конструктора нет, то у Throwable есть метод initCause(Throwable), который можно вызвать один раз, и передать ему исключение-причину.
Как и было сказано раньше, определение метода должно содержать список всех проверяемых исключений, которые метод может бросить. Также можно написать более общий класс, среди наследников которого есть эти исключения.
void f() throws InterruptedException, IOException { //...
try-catch-finally
Код, который может бросить исключения оборачивается в try-блок, после которого идут блоки catch и finally (Один из них может быть опущен).
try { // Код, который может сгенерировать исключение }
Сразу после блока проверки следуют обработчики исключений, которые объявляются ключевым словом catch.
try { // Код, который может сгенерировать исключение } catch(Type1 id1) { // Обработка исключения Type1 } catch(Type2 id2) { // Обработка исключения Type2 }
Сatch-блоки обрабатывают исключения, указанные в качестве аргумента. Тип аргумента должен быть классом, унаследованного от Throwable, или самим Throwable. Блок catch выполняется, если тип брошенного исключения является наследником типа аргумента и если это исключение не было обработано предыдущими блоками.
Код из блока finally выполнится в любом случае: при нормальном выходе из try, после обработки исключения или при выходе по команде return.
NB: Если JVM выйдет во время выполнения кода из try или catch, то finally-блок может не выполниться. Также, например, если поток выполняющий try или catch код остановлен, то блок finally может не выполниться, даже если приложение продолжает работать.
Блок finally удобен для закрытия файлов и освобождения любых других ресурсов. Код в блоке finally должен быть максимально простым. Если внутри блока finally будет брошено какое-либо исключение или просто встретится оператор return, брошенное в блоке try исключение (если таковое было брошено) будет забыто.
import java.io.IOException; public class ExceptionTest { public static void main(String[] args) { try { try { throw new Exception("a"); } finally { throw new IOException("b"); } } catch (IOException ex) { System.err.println(ex.getMessage()); } catch (Exception ex) { System.err.println(ex.getMessage()); } } }
После того, как было брошено первое исключение — new Exception("a") — будет выполнен блок finally, в котором будет брошено исключение new IOException("b"), именно оно будет поймано и обработано. Результатом его выполнения будет вывод в консоль b. Исходное исключение теряется.
Обработка исключений, вызвавших завершение потока
При использовании нескольких потоков бывают ситуации, когда поток завершается из-за исключения. Для того, чтобы определить с каким именно, начиная с версии Java 5 существует интерфейс Thread.UncaughtExceptionHandler. Его реализацию можно установить нужному потоку с помощью метода setUncaughtExceptionHandler. Можно также установить обработчик по умолчанию с помощью статического метода Thread.setDefaultUncaughtExceptionHandler.
Интерфейс Thread.UncaughtExceptionHandler имеет единственный метод uncaughtException(Thread t, Throwable e), в который передается экземпляр потока, завершившегося исключением, и экземпляр самого исключения. Когда поток завершается из-за непойманного исключения, JVM запрашивает у потока UncaughtExceptionHandler, используя метод Thread.getUncaughtExceptionHandler(), и вызвает метод обработчика – uncaughtException(Thread t, Throwable e). Все исключения, брошенные этим методом, игнорируются JVM.
Информация об исключениях
-
getMessage(). Этот метод возвращает строку, которая была первым параметром при создании исключения; -
getCause()возвращает исключение, которое стало причиной текущего исключения; -
printStackTrace()печатает stack trace, который содержит информацию, с помощью которой можно определить причину исключения и место, где оно было брошено.
Exception in thread "main" java.lang.IllegalStateException: A book has a null property
at com.example.myproject.Author.getBookIds(Author.java:38)
at com.example.myproject.Bootstrap.main(Bootstrap.java:14)
Caused by: java.lang.NullPointerException
at com.example.myproject.Book.getId(Book.java:22)
at com.example.myproject.Author.getBookIds(Author.java:35)
Все методы выводятся в обратном порядке вызовов. В примере исключение IllegalStateException было брошено в методе getBookIds, который был вызван в main. «Caused by» означает, что исключение NullPointerException является причиной IllegalStateException.
Разработка исключений
Чтобы определить собственное проверяемое исключение, необходимо создать наследника класса java.lang.Exception. Желательно, чтобы у исключения был конструкор, которому можно передать сообщение:
public class FooException extends Exception { public FooException() { super(); } public FooException(String message) { super(message); } public FooException(String message, Throwable cause) { super(message, cause); } public FooException(Throwable cause) { super(cause); } }
Исключения в Java7
- обработка нескольких типов исключений в одном
catch-блоке:
catch (IOException | SQLException ex) {...}
В таких случаях параметры неявно являются final, поэтому нельзя присвоить им другое значение в блоке catch.
Байт-код, сгенерированный компиляцией такого catch-блока будет короче, чем код нескольких catch-блоков.
-
Tryс ресурсами позволяет прямо вtry-блоке объявлять необходимые ресурсы, которые по завершению блока будут корректно закрыты (с помощью методаclose()). Любой объект реализующийjava.lang.AutoCloseableможет быть использован как ресурс.
static String readFirstLineFromFile(String path) throws IOException { try (BufferedReader br = new BufferedReader(new FileReader(path))) { return br.readLine(); } }
В приведенном примере в качестве ресурса использутся объект класса BufferedReader, который будет закрыт вне зависимосити от того, как выполнится try-блок.
Можно объявлять несколько ресурсов, разделяя их точкой с запятой:
public static void viewTable(Connection con) throws SQLException { String query = "select COF_NAME, SUP_ID, PRICE, SALES, TOTAL from COFFEES"; try (Statement stmt = con.createStatement(); ResultSet rs = stmt.executeQuery(query)) { //Work with Statement and ResultSet } catch (SQLException e) { e.printStackTrace; } }
Во время закрытия ресурсов тоже может быть брошено исключение. В try-with-resources добавленна возможность хранения «подавленных» исключений, и брошенное try-блоком исключение имеет больший приоритет, чем исключения получившиеся во время закрытия. Получить последние можно вызовом метода getSuppressed() от исключения брошенного try-блоком.
- Перебрасывание исключений с улучшенной проверкой соответствия типов.
Компилятор Java SE 7 тщательнее анализирует перебрасываемые исключения. Рассмотрим следующий пример:
static class FirstException extends Exception { } static class SecondException extends Exception { } public void rethrowException(String exceptionName) throws Exception { try { if ("First".equals(exceptionName)) { throw new FirstException(); } else { throw new SecondException(); } } catch (Exception ex) { throw e; } }
В примере try-блок может бросить либо FirstException, либо SecondException. В версиях до Java SE 7 невозможно указать эти исключения в декларации метода, потому что catch-блок перебрасывает исключение ex, тип которого — Exception.
В Java SE 7 вы можете указать, что метод rethrowException бросает только FirstException и SecondException. Компилятор определит, что исключение Exception ex могло возникнуть только в try-блоке, в котором может быть брошено FirstException или SecondException. Даже если тип параметра catch — Exception, компилятор определит, что это экземпляр либо FirstException, либо SecondException:
public void rethrowException(String exceptionName) throws FirstException, SecondException { try { // ... } catch (Exception e) { throw e; } }
Если FirstException и SecondException не являются наследниками Exception, то необходимо указать и Exception в объявлении метода.
Примеры исключений
- любая операция может бросить
VirtualMachineError. Как правило это происходит в результате системных сбоев. -
OutOfMemoryError. Приложение может бросить это исключение, если, например, не хватает места в куче, или не хватает памяти для того, чтобы создать стек нового потока. -
IllegalArgumentExceptionиспользуется для того, чтобы избежать передачи некорректных значений аргументов. Например:
public void f(Object a) { if (a == null) { throw new IllegalArgumentException("a must not be null"); } }
IllegalStateExceptionвозникает в результате некорректного состояния объекта. Например, использование объекта перед тем как он будет инициализирован.
Гарантии безопасности
При возникновении исключительной ситуации, состояния объектов и программы могут удовлетворять некоторым условиям, которые определяются различными типами гарантий безопасности:
- Отсутствие гарантий (no exceptional safety). Если было брошено исключение, то не гарантируется, что все ресурсы будут корректно закрыты и что объекты, методы которых бросили исключения, могут в дальнейшем использоваться. Пользователю придется пересоздавать все необходимые объекты и он не может быть уверен в том, что может переиспозовать те же самые ресурсы.
- Отсутствие утечек (no-leak guarantee). Объект, даже если какой-нибудь его метод бросает исключение, освобождает все ресурсы или предоставляет способ сделать это.
- Слабые гарантии (weak exceptional safety). Если объект бросил исключение, то он находится в корректном состоянии, и все инварианты сохранены. Рассмотрим пример:
class Interval { //invariant: left <= right double left; double right; //... }
Если будет брошено исключение в этом классе, то тогда гарантируется, что ивариант «левая граница интервала меньше правой» сохранится, но значения left и right могли измениться.
- Сильные гарантии (strong exceptional safety). Если при выполнении операции возникает исключение, то это не должно оказать какого-либо влияния на состояние приложения. Состояние объектов должно быть таким же как и до вызовов методов.
- Гарантия отсутствия исключений (no throw guarantee). Ни при каких обстоятельствах метод не должен генерировать исключения. В Java это невозможно, например, из-за того, что
VirtualMachineErrorможет произойти в любом месте, и это никак не зависит от кода. Кроме того, эту гарантию практически невозможно обеспечить в общем случае.
Источники
- Обработка ошибок и исключения — Сайт Георгия Корнеева
- Лекция Георгия Корнеева — Лекториум
- The Java Tutorials. Lesson: Exceptions
- Обработка исключений — Википедия
- Throwable (Java Platform SE 7 ) — Oracle Documentation
- try/catch/finally и исключения — www.skipy.ru
Introduction to try catch exception handling in Java
Errors occur frequently while coding in any programming language. Sometimes, we may misspell a name or keyword, or sometimes we unknowingly change the symbols. These are very common and easy to handle errors. But there are some errors that are not that much easy to handle, we need a special block of codes to handle such complex errors.
In this tutorial, we will learn how we can handle different errors and exceptions in java programming using the try catch java block method. We will first learn the basic syntax of the java try and catch method and will solve some of the exceptions by taking various examples. Moreover, we will also cover different types of exceptions and errors that are common in a java programming language.
ALSO READ: List vs LinkedList in Java Explained [Practical Examples]
Towards the end of this tutorial, we will also learn about throw and finally keywords and see how they are useful in handling exceptions. In a nutshell, this tutorial is going to have all the details about the java try and catch block method to handle errors and exceptions.
Getting started with try catch Java method
When an error or exception occurs, the java program stops execution further. So in order to continue the execution we have to solve the errors and exceptions by using different java error and exception handling methods. Before going into the details of error and exception handling in java, let us first understand what an error and exception are? In this section, we will define errors and exceptions and their different types in java.
Different Java Error Types
In Java, an error is a subclass of Throwable that tells that something serious problem is existing and a reasonable Java application should not try to catch that error. As these errors are abnormal conditions and should not occur, thus, error and its subclass are referred to as Unchecked Exceptions. Basically, there are two types of java errors which are listed below:
- Compile-time errors: Compile-time errors are the errors resulting from a violation of programming language’s grammar rules, for example writing syntactically incorrect statements. See the example of java compile-time error below:
ALSO READ: Different Java data types explained with Examples
![Try Catch in Java Explained [Exception Handling Examples]](https://www.golinuxcloud.com/wp-content/uploads/java-try-catch-and-syntax-erro-e1630737632159.png "Try Catch in Java Explained [Exception Handling Examples]")
-
Run-time errors: Runtime errors occur during runtime or execution of the program because of unexpected situations. Some of the common run-time errors include zero division, invalid input, accessing the array beyond the range and etc. We use the exception handling method of Java to handle such errors. See the example below which gives run-time error when divided by zero.
// class
public class Main {
public static void main(String[] args){
System.out.println(6/0);
}
}Output:
Exception in thread "main" java.lang.ArithmeticException: / by zero
at Main.main(Main.java:4)
Different Java Exception Types
Exception in Java is an event that interrupts the execution of program instructions and disturbs the normal flow of program execution. It is an object that wraps an error event information that occurred within a method and it is passed to the runtime system. There are two types of java exceptions which are listed below:
-
Checked Exceptions: Checked Exceptions are also called compile-time exceptions because they occur at the compile time. If the method contains the code that throws a checked exception, the programmer must provide a mechanism to catch it in the same method. An example of a checked exception can be
SQLException. -
Unchecked Exceptions: Java Unchecked Exceptions are also called Runtime Exceptions because they occur at runtime. This occurs during the execution of the program. It totally depends upon the developer to catch the runtime or unchecked exceptions. The examples are
ArithmeticException,NullPointerException, etc.
ALSO READ: Java Arguments vs Parameters [Syntax & Examples]
Exception handling in Java programming language
Exception handling is a transparent way to handle program errors. It helps us to separate the error-handling code from the normal code and enhances readability. In this section, we will have a close look at the java exception handling method and will see how we can use the java try and catch method along with various examples.
The Syntax of Java try block
The try block in Java contains the statements where there is a chance of exception. A catch block always follows the try block. The simple syntax of java try blocks looks like this;
try{
// statements
}
It is always recommended to use java try block if you think that certain statements in a program can throw an exception. A try block is always followed by a catch block.
The syntax of Java catch block
A catch block is a block where we can handle the exceptions. The catch block must always follow the try block. There can be multiple catch blocks in a try block. The simple syntax looks like this;
catch(expectionType){
// statements
}So, now the syntax of the java try and catch method looks like this;
// try catch java blocks
try{
//statements
}
catch(exceptionType){
// statements
}Now let us take an example and see how we can handle an error using the java try and catch method.
Example-1: Handle error using try catch Java method
In this section, we will take an example of zero division error and handle it using the java try and catch blocks. See the program below:
// class
public class Main {
public static void main(String[] args){
// try catch java blocks
// try block
try{
// zero division
System.out.println(6/0);
}
// catch block
catch(Exception e){
// giving out message
System.out.println("Zero division error");
}
}
}
Output:
Zero division error
Notice that we were able to catch the error and handle it without getting terminated from the program.
ALSO READ: Java Regular Expression (RegEx) Explained [Easy Examples]
Example-2: Handle error using multiple try catch Java blocks
In some cases, we might want to know what kind of error occurs in the try block. In such cases, we can use multiple catch blocks with different possible exceptions. See the example below which uses multiple java try and catch blocks.
// class
public class Main {
public static void main(String[] args){
// try catch java blocks
// try block
try{
// zero division
System.out.println(6/0);
}
// catch block
catch(ArithmeticException e){
// giving out message
System.out.println("Zero division error");
}
// catch block
catch(ArrayIndexOutOfBoundsException e){
System.out.println("Index out of range!!");
}
}
}Output:
Zero division error
Notice that we had specified the type of exception inside the round brackets in the catch block. So, when an error occurs in the try block, then depending on the type of exception the catch block will execute. See the example below which tries to print an element that does not exist in an array.
// class
public class Main {
public static void main(String[] args){
// java array
int arr[] = {1, 2, 3, 4};
// try catch java blocks
// try block
try{
// printing element
System.out.println(arr[5]);
}
// catch block
catch(ArithmeticException e){
// giving out message
System.out.println("Zero division error");
}
// catch block
catch(ArrayIndexOutOfBoundsException e){
System.out.println("Index out of range!!");
}
}
}Output:
Index out of range!!
Notice that when we tried to print the element which does not exist we get an «array index out of range» error and accordingly the catch block was executed.
ALSO READ: Java read file using 5+ methods [Easy Examples]
Example-3: Printing the Java exception
We already have learned how we can handle an exception using the java try and catch block. In some cases, we might also want to print out the error to display to the user. We can do that by printing the error as it is. See the example below:
// class
public class Main {
public static void main(String[] args){
// java array
int arr[] = {1, 2, 3, 4};
// try catch java blocks
// try block
try{
// printing element
System.out.println(arr[5]);
}
// catch block
catch(Exception e){
// printing the exception
System.out.println("The execption is: n"+e);
}
}
}Output:
The execption is:
java.lang.ArrayIndexOutOfBoundsException: Index 5 out of bounds for length 4
Notice that we were able to print out the type of exception without knowing it. Now, let us take one more example and print out the exception. See the example below:
// class
public class Main {
public static void main(String[] args){
//try catch java blocks
// try block
try{
// printing element
System.out.println(6/0);
}
// catch block
catch(Exception e){
// printing the exception
System.out.println("The execption is: n"+e);
}
}
}
Output:
The execption is:
java.lang.ArithmeticException: / by zero
Notice that we are able to get the exception type by simply printing it.
More about Java exception handling
Apart from the try and catch block, we can also use java throws and finally keywords to handle java exceptions and errors as well. In this section, we will see how we can use throws and finally blocks in java exception handling by taking various examples.
ALSO READ: Java Arrays.asList Explained [Practical Examples]
Throw keyword and Java exception handling
The throws is a keyword used to indicate that this method can throw a specified type of exception. The caller has to handle the exception using a try-catch block or propagate the exception. We can throw either checked or unchecked exceptions using the throws keyword. With the help of the throws keyword, we can provide information to the caller of the method about the types of exceptions the method might throw. The simple syntax looks like this;
MethodName(parameter) throws exception
Now let us take an example and see how it actually works. First, let us have a look at the example without using the throws keyword. See the example below:
// class
public class Main {
public static void main(String[] args)
{
Thread.sleep(100);
System.out.println("Print successfully");
}
}Output:
![Try Catch in Java Explained [Exception Handling Examples]](https://www.golinuxcloud.com/wp-content/uploads/try-catch-java-error-e1630737711279.png "Try Catch in Java Explained [Exception Handling Examples]")
In the above program, we are getting the compile-time error because there is a chance of an exception if the main thread is going to sleep. Now let us use the throws keyword to handle the above-given error. See the example below:
// class
public class Main {
public static void main(String[] args)throws InterruptedException
{
Thread.sleep(100);
System.out.println("Print successfully");
}
}Output:
Print successfully
Finally keyword in Java exception handling
The finally keyword in java is used to put important codes such as clean up code e.g. closing the file or closing the connection. The finally block executes whether exception rise or not and whether exception is handled or not. A finally contains all the crucial statements regardless of the exception occurs or not. The simple syntax looks like this;
finally{
// important statements
}
Now let us use the finally block along with try catch java block. See the example below:
// class
public class Main {
public static void main(String[] args)
// try catch java blocks
{
// try block
try{
System.out.println(9/3);
}
// catch
catch (Exception e){
System.out.println("Exception occurs");
}
// finally
finally{
System.out.println("successfully executed!");
}
}
}
Output:
3
successfully executed!
Notice that there was no error and the finally block was executed. Now let us take an example of having an execption with finally keyword. See the example below:
// class
public class Main {
public static void main(String[] args)
// try catch java blocks
{
// try block
try{
System.out.println(9/0);
}
// catch
catch (Exception e){
System.out.println("Exception occurs");
}
// finally
finally{
System.out.println("successfully executed!");
}
}
}Output:
Exception occurs
successfully executed!
Notice that the finally block was still executed after handling an exception as well. We can conclude that the finally block will be executed with or without having exceptions.
ALSO READ: How to split String into Array [Practical Examples]
Summary
While writing code, we may come across various different kinds of errors and exception and the best way is to handle those exceptions using build in error and exception handling methods. In this tutorial, we learned about try catch java method to handle java exceptions. We first covered different kinds of exceptions that might occur in our program and then solve various examples to handle exceptions using the java try and catch block method.
Moreover, we also learned about the usage of throws and finally keyword in exception handling. All in all, this tutorial is one of the informative tutorials about java try and catch blocks and exception handling.
Further Reading
Try block
catch blocks
exception handling in java