Чем отличаются исключения от обычных классов java

Чем отличаются исключения от обычных классов java

Базовым классом для всех исключений является класс Throwable . От него уже наследуются два класса: Error и Exception . Все остальные классы являются производными от этих двух классов.

Класс Error описывает внутренние ошибки в исполняющей среде Java. Программист имеет очень ограниченные возможности для обработки подобных ошибок.

Собственно исключения наследуются от класса Exception. Среди этих исключений следует выделить класс RuntimeException . RuntimeException является базовым классом для так называемой группы непроверяемых исключений (unchecked exceptions) — компилятор не проверяет факт обработки таких исключений и их можно не указывать вместе с оператором throws в объявлении метода. Такие исключения являются следствием ошибок разработчика, например, неверное преобразование типов или выход за пределы массива.

Некоторые из классов непроверяемых исключений:

• ArithmeticException : исключение, возникающее при делении на ноль
• IndexOutOfBoundException : индекс вне границ массива
• IllegalArgumentException : использование неверного аргумента при вызове метода
• NullPointerException : использование пустой ссылки
• NumberFormatException : ошибка преобразования строки в число

Все остальные классы, образованные от класса Exception, называются проверяемыми исключениями (checked exceptions).

Некоторые из классов проверяемых исключений:

• CloneNotSupportedException : класс, для объекта которого вызывается клонирование, не реализует интерфейс Cloneable
• InterruptedException : поток прерван другим потоком
• ClassNotFoundException : невозможно найти класс

Подобные исключения обрабатываются с помощью конструкции try..catch. Либо можно передать обработку методу, который будет вызывать данный метод, указав исключения после оператора throws:

public Person clone() throws CloneNotSupportedException

В итоге получается следующая иерархия исключений:

Поскольку все классы исключений наследуются от класса Exception, то все они наследуют ряд его методов, которые позволяют получить информацию о характере исключения. Среди этих методов отметим наиболее важные:

• Метод getMessage() возвращает сообщение об исключении
• Метод getStackTrace() возвращает массив, содержащий трассировку стека исключения
• Метод printStackTrace() отображает трассировку стека

try < int x = 6/0; >catch(Exception ex)

Исключения и ошибки в Java

В нашей жизни нередко возникают ситуации, которые мы не планировали. К примеру, пошли вы утром умываться и с досадой обнаружили, что отключили воду. Вышли на улицу, сели в машину, а она не заводится. Позвонили другу, а он недоступен. И так далее и тому подобное… В большинстве случаев человек без труда справится с подобными проблемами. А вот как с непредвиденными ситуациями справляется Java, мы сейчас и поговорим.

Что называют исключением. Исключения в мире программирования

В программировании исключением называют возникновение ошибки (ошибок) и различных непредвиденных ситуаций в процессе выполнения программы. Исключения могут появляться как в итоге неправильных действий юзера, так и из-за потери сетевого соединения с сервером, отсутствии нужного ресурса на диске и т. п. Также среди причин исключений — ошибки программирования либо неверное использование API.

При этом в отличие от «человеческого мира», программное приложение должно чётко понимать, как поступать в подобной ситуации. И вот как раз для этого в Java и существует механизм исключений (exception).

Используемые ключевые слова

При обработке исключений в Java применяются следующие ключевые слова: — try – служит для определения блока кода, в котором может произойти исключение; — catch – необходим для определения блока кода, где происходит обработка исключения; — finally – применяется для определения блока кода, являющегося необязательным, однако при его наличии он выполняется в любом случае вне зависимости от результата выполнения блока try.

Вышеперечисленные ключевые слова необходимы для создания в коде ряда специальных обрабатывающих конструкций: try<>finally<> , try<>catch , try<>catch<>finally .

Кроме того: 1. Для возбуждения исключения используем throw. 2. Для предупреждения в сигнатуре методов о том, что метод может выбросить исключение, применяем throws.

Давайте на примере посмотрим, как используются ключевые слова в Java-программе:

 
//метод считывает строку с клавиатуры public String input() throws MyException //предупреждаем с помощью throws, // что метод может выбросить исключение MyException BufferedReader reader = new BufferedReader(new InputStreamReader(System.in)); String s = null; //в блок try заключаем код, в котором может произойти исключение, в данном // случае компилятор нам подсказывает, что метод readLine() класса // BufferedReader может выбросить исключение ввода/вывода try  s = reader.readLine(); // в блок catch заключаем код по обработке исключения IOException > catch (IOException e)  System.out.println(e.getMessage()); // в блоке finally закрываем поток чтения > finally  // при закрытии потока тоже возможно исключение, например, если он не был открыт, поэтому “оборачиваем” код в блок try try  reader.close(); // пишем обработку исключения при закрытии потока чтения > catch (IOException e)  System.out.println(e.getMessage()); > > if (s.equals(""))  // мы решили, что пустая строка может нарушить в дальнейшем работу нашей программы, например, на результате этого метода нам надо вызывать метод substring(1,2), поэтому мы вынуждены прервать выполнение программы с генерацией своего типа исключения MyException с помощью throw throw new MyException("String can not be empty!"); > return s; > 
Зачем нам механизм исключений?
Для понимания опять приведём пример из обычного мира. Представьте, что на какой-нибудь автодороге имеется участок с аварийным мостом, на котором ограничена грузоподъёмность. И если по такому мосту проедет грузовик со слишком большой массой, мост разрушится, а в момент этого ЧП ситуация для шофёра станет, мягко говоря, исключительной. И вот, дабы такого не произошло, дорожные службы заранее устанавливают на дороге соответствующие предупреждающие знаки. И тогда водитель, посмотрев на знак, сравнит массу своего авто со значением разрешённой грузоподъёмности и примет соответствующее решение, например, поедет по другой дороге.
То есть мы видим, что из-за правильных действий дорожной службы шоферы крупногабаритных транспортных средств: 1) получили возможность заранее изменить свой путь; 2) были предупреждены об опасности; 3) были предупреждены о невозможности проезжать по мосту при определённых условиях.
Вот как наш жизненный пример соотносится с применением исключения на Java:

Исходя из вышесказанного, мы можем назвать одну из причин применения исключений в Java. Заключается она в возможности предупреждения исключительной ситуации для её последующего разрешения и продолжения работы программы. То есть механизм исключений позволит защитить написанный код от неверного применения пользователем путём валидации входящих данных.
Что же, давайте ещё раз побудем дорожной службой. Чтобы установить знак, мы ведь должны знать места, где водителей ТС могут ждать различные неприятности. Это первое. Далее, нам ведь надо заготовить и установить знаки. Это второе. И, наконец, надо предусмотреть маршруты объезда, позволяющие избежать опасности.
В общем, механизм исключений в Java работает схожим образом. На стадии разработки программы мы выполняем «ограждение» опасных участков кода в отношении наших исключений, используя блок try<> . Чтобы предусмотреть запасные пути, применяем блок catch<> . Код, выполняемый в программе при любом исходе, пишем в блоке finally<> .
Иногда бывает, что мы не можем предусмотреть «запасной аэродром» либо специально желаем предоставить право его выбора юзеру. Но всё равно мы должны как минимум предупредить пользователя об опасности. Иначе он превратится в разъярённого шофёра, который ехал долго, не встретил ни одного предупреждающего знака и в итоге добрался до аварийного моста, проехать по которому не представляется возможным.
Что касается программирования на Java, то мы, когда пишем свои классы и методы, далеко не всегда можем предвидеть контекст их применения другими программистами в своих программах, а значит, не можем со стопроцентной вероятностью предвидеть правильный путь для разрешения исключительных ситуаций. Но предупредить коллег о возможной исключительной ситуации мы всё-таки должны, и это не что иное, как правило хорошего тона.
Выполнить это правило в Java нам как раз и помогает механизм исключений с помощью throws. Выбрасывая исключение, мы, по сути, объявляем общее поведение нашего метода и предоставляем пользователю метода право написания кода по обработке исключения.
Предупреждаем о неприятностях
Если мы не планируем обрабатывать исключение в собственном методе, но желаем предупредить пользователей метода о возможной исключительной ситуации, мы используем, как это уже было упомянуто, ключевое слово throws. В сигнатуре метода оно означает, что при некоторых обстоятельствах метод может выбросить исключение. Это предупреждение становится частью интерфейса метода и даёт право пользователю на создание своего варианта реализации обработчика исключения.
После упоминания ключевого слова throws мы указываем тип исключения. Как правило, речь идёт о наследниках класса Exception Java. Но так как Java — это объектно-ориентированный язык программирования, все исключения представляют собой объекты.

Иерархия исключений в Java
Когда возникают ошибки при выполнении программы, исполняющая среда Java Virtual Machine обеспечивает создание объекта нужного типа, используя иерархию исключений Java — речь идёт о множестве возможных исключительных ситуаций, которые унаследованы от класса Throwable — общего предка. При этом исключительные ситуации, которые возникают в программе, делят на 2 группы: 1. Ситуации, при которых восстановление нормальной дальнейшей работы невозможно. 2. Ситуации с возможностью восстановления.
К первой группе можно отнести случаи, при которых возникают исключения, которые унаследованы из класса Error. Это ошибки, возникающие во время выполнения программы при сбое работы Java Virtual Machine, переполнении памяти либо сбое системы. Как правило, такие ошибки говорят о серьёзных проблемах, устранение которых программными средствами невозможно. Данный вид исключений в Java относят к неконтролируемым исключениям на стадии компиляции (unchecked). К этой же группе относятся и исключения-наследники класса Exception, генерируемые Java Virtual Machine в процессе выполнения программы — RuntimeException. Данные исключения тоже считаются unchecked на стадии компиляции, а значит, написание кода по их обработке необязательно.
Что касается второй группы, то к ней относят ситуации, которые можно предвидеть ещё на стадии написания приложения, поэтому для них код обработки должен быть написан. Это контролируемые исключения (checked). И в большинстве случаев Java-разработчики работают именно с этими исключениями, выполняя их обработку.
Создание исключения
В процессе исполнения программы исключение генерируется Java Virtual Machine либо вручную посредством оператора throw. В таком случае в памяти происходит создание объекта исключения, выполнение основного кода прерывается, а встроенный в JVM обработчик исключений пробует найти способ обработать это самое исключение.
Обработка исключения
Обработка исключений в Java подразумевает создание блоков кода и производится в программе посредством конструкций try<>finally<> , try<>catch , try<>catch<>finally .

В процессе возбуждения исключения в try обработчик исключения ищется в блоке catch, который следует за try. При этом если в catch присутствует обработчик данного вида исключения, происходит передача управления ему. Если же нет, JVM осуществляет поиск обработчика данного типа исключения, используя для этого цепочку вызова методов. И так происходит до тех пор, пока не находится подходящий catch. После того, как блок catch выполнится, управление переходит в необязательный блок finally. Если подходящий блок catch найден не будет, Java Virtual Machine остановит выполнение программы, выведя стек вызовов методов под названием stack trace. Причём перед этим выполнится код блока finally при наличии такового.
Рассмотрим практический пример обработки исключений:
 
public class Print  void print(String s)  if (s == null)  throw new NullPointerException("Exception: s is null!"); > System.out.println("Inside method print: " + s); > public static void main(String[] args)  Print print = new Print(); List list= Arrays.asList("first step", null, "second step"); for (String s:list)  try  print.print(s); > catch (NullPointerException e)  System.out.println(e.getMessage()); System.out.println("Exception was processed. Program continues"); > finally  System.out.println("Inside bloсk finally"); > System.out.println("Go program. "); System.out.println("-----------------"); > > > 
А теперь глянем на результаты работы метода main:
 
Inside method print: first step Inside bloсk finally Go program. ----------------- Exception: s is null! Exception was processed. Program continues Inside bloсk finally Go program. ----------------- Inside method print: second step Inside bloсk finally Go program. ----------------- 
Блок finally чаще всего используют, чтобы закрыть открытые в try потоки либо освободить ресурсы. Но при написании программы уследить за закрытием всех ресурсов возможно не всегда. Чтобы облегчить жизнь разработчикам Java, была предложена конструкция try-with-resources , автоматически закрывающая ресурсы, открытые в try. Используя try-with-resources , мы можем переписать наш первый пример следующим образом:
 
public String input() throws MyException  String s = null; try(BufferedReader reader = new BufferedReader(new InputStreamReader(System.in))) s = reader.readLine(); > catch (IOException e)  System.out.println(e.getMessage()); > if (s.equals("")) throw new MyException ("String can not be empty!"); > return s; > 
А благодаря появившимся возможностям Java начиная с седьмой версии, мы можем ещё и объединять в одном блоке перехват разнотипных исключений, делая код компактнее и читабельнее:
 
public String input()  String s = null; try (BufferedReader reader = new BufferedReader(new InputStreamReader(System.in)))  s = reader.readLine(); if (s.equals(""))  throw new MyException("String can not be empty!"); > > catch (IOException | MyException e)  System.out.println(e.getMessage()); > return s; > 
Итоги
Итак, применение исключений в Java повышает отказоустойчивость программы благодаря использованию запасных путей. Кроме того, появляется возможность отделить код обработки исключительных ситуаций от логики основного кода за счёт блоков catch и переложить обработку исключений на пользователя кода посредством throws.
Основные вопросы об исключениях в Java
1.Что такое проверяемые и непроверяемые исключения? Если говорить коротко, то первые должны быть явно пойманы в теле метода либо объявлены в секции throws метода. Вторые вызываются проблемами, которые не могут быть решены. Например, это нулевой указатель или деление на ноль. Проверяемые исключения очень важны, ведь от других программистов, использующих ваш API, вы ожидаете, что они знают, как обращаться с исключениями. К примеру, наиболее часто встречаемое проверяемое исключение — IOException, непроверяемое — RuntimeException. 2.Почему переменные, определённые в try, нельзя использовать в catch либо finally? Давайте посмотрим на нижеследующий код. Обратите внимание, что строку s, которая объявлена в блоке try, нельзя применять в блоке catch. То есть данный код не скомпилируется.
 
try  File file = new File("path"); FileInputStream fis = new FileInputStream(file); String s = "inside"; > catch (FileNotFoundException e)  e.printStackTrace(); System.out.println(s); > 
А всё потому, что неизвестно, где конкретно в try могло быть вызвано исключение. Вполне вероятно, что оно было вызвано до объявления объекта. 3.Почему Integer.parseInt(null) и Double.parseDouble(null) вызывают разные исключения? Это проблема JDK. Так как они были разработаны разными людьми, то заморачиваться вам над этим не стоит:
 
Integer.parseInt(null); // вызывает java.lang.NumberFormatException: null Double.parseDouble(null); // вызывает java.lang.NullPointerException 
4.Каковы основные runtime exceptions в Java? Вот лишь некоторые из них:
 
IllegalArgumentException ArrayIndexOutOfBoundsException
Их можно задействовать в операторе if, если условие не выполняется:
 
if (obj == null)  throw new IllegalArgumentException("obj не может быть равно null"); 
5.Возможно ли поймать в одном блоке catch несколько исключений? Вполне. Пока классы данных исключений можно отследить вверх по иерархии наследования классов до одного и того же суперкласса, возможно применение только этого суперкласса. 6.Способен ли конструктор вызывать исключения? Способен, ведь конструктор — это лишь особый вид метода.
 
class FileReader public FileInputStream fis = null; public FileReader() throws IOException File dir = new File(".");//get current directory File fin = new File(dir.getCanonicalPath() + File.separator + "not-existing-file.txt"); fis = new FileInputStream(fin); > > 
7.Возможен ли вызов исключений в final? В принципе, можете сделать таким образом:
 
public static void main(String[] args)  File file1 = new File("path1"); File file2 = new File("path2"); try  FileInputStream fis = new FileInputStream(file1); > catch (FileNotFoundException e)  e.printStackTrace(); > finally  try  FileInputStream fis = new FileInputStream(file2); > catch (FileNotFoundException e)  e.printStackTrace(); > > > 
Но если желаете сохранить читабельность, объявите вложенный блок try-catch в качестве нового метода и вставьте вызов данного метода в блок finally.
 
finally. public static void main(String[] args)  File file1 = new File("path1"); File file2 = new File("path2"); try  FileInputStream fis = new FileInputStream(file1); > catch (FileNotFoundException e)  e.printStackTrace(); > finally  methodThrowException(); > > 
Чем отличаются исключения от обычных классов java
Последнее изменение: 28 октября 2007г.
try / catch / finally и исключения
Думаю, вряд ли найдется Java-разработчик, который хотя бы не слышал об исключениях. В принципе, они не являются исключительным свойством Java, есть они и в Delphi, и в C++. Однако в Java исключения используются особенно широко. И чаще всего с ними связано немало ошибок. Основная цель этой статьи – систематизация информации об исключениях, их обработке и т.п. А именно:

Исключение как явление
Классификация исключений

java.lang.Exception
java.lang.RuntimeException
java.lang.Error

Исключение как явление
Что такое вообще исключение? Это сигнал о нестандартной – исключительной – ситуации. Ситуации могут быть самые различные – ожидаемые или нет, разной степени критичности. И относиться к этим ситуациям, естественно, приходится по-разному.
Как и всё в Java, исключения тоже представленны в виде классов. Корнем иерархии служит класс java.lang.Throwable , дословно – "бросаемый". Его прямыми наследниками являются java.lang.Exception и java.lang.Error, от которых и унаследованы все остальные исключения. И от которых рекомендуется наследовать собственные.
Хочу подчеркнуть, что исключения не есть нечто из ряда вон выходящее. Это нормальный механизм. Потому не стоит стараться избегать их использования любой ценой. И тем более не стоит стараться избегать исключений в конструкторах, к чему склонны разработчики, хорошо знакомые с С++. Ввиду наличия сборщика мусора утечек памяти в этом случае не будет. Разве что очень постараться, я имею в виду намеренно.
Теперь рассмотрим типы исключений ближе.
Классификация исключений
Как я уже упоминал, есть два "базовых" типа исключений – java.lang.Exception и java.lang.Error. Я бы сказал, что различаются степенью критичности. Не, разумеется, оба типа могут быть перехвачены, ибо перехватывается исключение начиная с уровня java.lang.Throwable . Это разделение скорее логическое. Если произошло что-то серьезное – не найден метод, который надо вызвать, закончилась память, переполнение стека, в общем, что-то, после чего восстановить нормальную работу уже вряд ли реально – это ошибка, java.lang.Error. Если продолжение работы теоретически возможно – это исключение, java.lang.Exception.
Кроме уже упомянутых двух типов существует также еще один класс, являющийся существенным – java.lang.RuntimeException. Он унаследован от java.lang.Exception и является корнем для всех исключений времени выполнения – т.е. возникающих при работе виртуальной машины. Нулевые ссылки, деление на ноль, неверное значение аргумента, выход за пределы массивы и т.п. – все это исключительные ситуации времени выполнения. Чем они отличаются от обычных, мы рассмотрим ниже.
Поскольку исключения – точно такие же классы, в них можно включать и собственные переменные, и даже какую-то логику. Увлекаться, правда, не стоит. Дело в том, что исключение – класс все-таки выделенный. При создании Throwable существуют большие накладные расходы – заполнение стека вызова. Это достаточно длительная процедура. И потому создавать исключение просто так – себе дороже. Его нужно создавать только тогда, когда без него не обойтись, когда оно точно будет выброшено. Проще это делать сразу вместе с директивой throw .
А вот держать в классе исключения какую-то информацию, которая позволит его обработать – вполне допустимо. Передавать эту информацию лучше через конструктор.
Итак, приступим к более подробному рассмотрению. Первый базовый тип –
java.lang.Exception
Исключения этого типа я бы охарактерировал так – они возникают в ситуациях, которые нам неподконтрольны. Скажем, десериализуем мы класс, а данные в неверном формате. И мы с этим ничего не можем сделать, кроме как адекватно отреагировать.
Любое исключение типа java.lang.Exception должно быть обработано. Это закон. За его исполнением следит компилятор. Если исключение не обработано в методе – оно должно быть декларировано в его сигнатуре и в этом случае обработано выше. Или еще выше. Но обработано оно будет. Единственное исключение – это java.lang.RuntimeException, о котором мы поговорим дальше.
Метод может декларировать любое количестко исключений. Нет, любое – это, наверное, слишком сильно сказано. Если мне не изменяет память, количество исключений ограничено 64K – 65536 штук. Для меня это уже означает, что я могу декларировать столько исключений, сколько мне заблагорассудится.
java.lang.RuntimeException
Не знаю, насколько со мной согласятся, но я бы охарактеризовал этит тип так: java.lang.RuntimeException – это ошибки разработчика . Неверное состояние монитора, деление на ноль, неверный аргумент, нулевая ссылка, выход за границы массива, неверное состояние класса – все это можно предусмотреть и предупредить. Еще раз полностью просмотрев всю иерархию исключений времени выполнения, я не нашел ни одного, которого нельзя было бы избежать какой-нибудь проверкой.
Поскольку ожидать ошибок – глупо, исключения типа java.lang.RuntimeException не декларируются. Компилятор это допускает, соответственно, позволяя их не обрабатывать. Более того, я бы сказал, что ловить java.lang.RuntimeException – дурной тон, ибо вместо того, чтобы устранять причину, мы нейстрализуем последствия. И хуже всего то, что ошибки разработчика устранить во время выполнения практически нереально, фактически, они по степени критичности приближены к java.lang.Error.
Перейдем теперь к последнему типу –
java.lang.Error
Как я уже упоминал, это критические ошибки, после которых восстановить нормальную работу практически нереально. В самом деле – ну что сделаешь при переполнении стека? Или если не найден метод? Или если вызван абстрактный метод? Или в случае ошибки в байт-коде класса? Абсолютно ничего. По крайней мере, без серьезного вмешательства человека, который может заменить библиотеку, например. Или поменять classpath .
В некоторых случаях ситуация не столь критична. Скажем, нехватка памяти, вызывающая java.lang.OutOfMemoryError . Если эта ошибка произошла в момент выделения большого объема памяти – например, при создании массива, – ее можно перехватить и попытаться выделить память в меньших объемах, изменив каким-то образом алгоритм, который будет эту память использовать.
Или, скажем, в случае, когда не JVM поддерживает системную кодировку – при попытке создать InputStreamReader без указания кодировки будет выброшена ошибка. Однако нужна ли нам системная кодировка и насколько для нас критично ее отсутствие – решать нам.
Как и в случае с java.lang.RuntimeException компилятор разрешает не декларировать и не обрабатывать ошибки из иерархии java.lang.Error . Перехватывать их или нет – решать вам. Зависит от того, можете ли вы предложить приемлемый алгоритм для восстановления.
С классификацией закончили, переходим к следующему вопросу.
Инициация исключений
А вопрос следующий – что и когда бросать.
Представим себе, что у вас создалась исключительная ситуация и работать код дальше не может. Какой именно тип исключения использовать?
Тут самое время воспользоваться характеристиками исключений, приведенными выше. Если возникшая исключительная ситуация такова, что дальнейшая работа невозможна в принципе – можно бросить исключение из иерархии java.lang.Error. Хотя у меня лично таких ситуаций не было в практике. Если исключительная ситуация возникла по вине внешних обстоятельств или пользователя приложения – не те данные дали, например, – то это случай, когда ошибки должны быть обработаны, следовательно, лучше всего использовать java.lang.Exception. Если же ситуация возникла по вине разработчика – например, передали вам в качестве параметра null , при том что в javadoc вы английским по белому написали, что этого делать нельзя – тогда это java.lang.RuntimeException.
При написании бизнес-логики – в особенности это касается библиотек – часто бывает полезным создать собственный тип исключения. Просто для того, чтобы дать возможность обрабатывать ваши исключения отдельно от остальных. Подробнее об обработке – в следующем разделе.
Пара слов насчет приведенного примера – null в качестве параметра. Теоретически в этой ситуации можно бросить два исключения – NullPointerException и IllegalArgumentException . Нескотря на кажущуюся очевидность выбора я лично предпочитаю второй вариант. На мой взгляд NullPointerException должна бросать исключительно виртуальная машина. Если же я сам проверил значение и убедился, что оно равно null , а этого быть не должно – гораздо более информативно использовать IllegalArgumentException , если это значение аргумента, или же IllegalStateException – если это значение члена класса.
Ну ладно, что бросить именно – это мы как-нибудь определим. Но иногда возникает какое-то иррациональное желание не только бросить исключение, но и как-то его конкретизировать, указав причину. Не, можно, конечно, и по исключению на каждую ошибку создать, но сойти с ума намного проще и быстрее.
Первый вариант, который видится – текстовое сообщение. Практически у любого класса исключения есть конструктор, принимающий в качестве параметра текст. Именно этот текст фигурирует в консоли при печати сообщения об исключени, его же можно получить через getMessage() . Это позлезно, когда ошибку обнаруживаем мы сами. А что делать, когда ошибка для нас тоже "внешняя", скажем – мы поймали исключение, брошенное глубже?
В этом случае может выручить механизм т.н. exception chaining – связывания исключений. Практически у каждого класса исключения есть конструктор, принимающий в качестве параметра Throwable – причину исключительной ситуации. Если же такого конструктора нет – у все того же Throwable , от которого унаследованы все исключения, есть метод initCause(Throwable) , который можно вызвать ровно один раз. И передать ему исключение, явившееся причиной того, что было инициировано следующее исключение.
Зачем это нужно. Дело в том, что хорошо спроектированный код – он как черный ящик. У него есть свои интерфейсы, определенное поведение, набор исключительных ситуаций, наконец. А что происходит внутри – это не играет роли для того, что находится снаружи. Более того – иногда может сыграть и обратный эффект. Причин для ошибки может быть добрый десяток, и ловить их все отдельно и так же обрабатывать. Чаще всего просто не нужно. Именно потому проще определить, например, свое исключение (ну или использовать имеющееся, не суть важно) и бросить именно его, указав как причину то, которое мы поймали. И волки сыты, и пользователям кода работы меньше.
Ну вот, от инициации исключений мы плавно переходим к их обработке.
Обработка исключений
Казалось бы, чего проще? Написал catch(Throwable th) – и всё. Однако именно от этого я их хочу предостеречь.
Во-первых, как я уже говорил выше, ловить исключения времени выполнения – дурной тон. Они свидетельствуют об ошибках. Ловить java.lang.Error или производные стоит только если вы точно знаете, что делаете. Восстановление после таких ошибок не всегда возможно и почти всегда нетривиально.
Во-вторых – как именно обрабатывать? Я об этом подробно писал в статье о качестве кода, раздел Обработка исключений, но повторюсь. По каждому пойманому исключению необходимо принимать решение. Просто проглотить его или вывести в консоль – самое неприятное, что можно придумать. А этим грешат, к сожалению, многие. Человек читает XML из файла, получает исключение, глотает его – и пытается дальше работать с этим XML так, как будто ничего не произошло. Естественно получает NullPointerException , поскольку класс, который он использует, не инициализировался. Ошибка разработчика, хотя и не столь очевидная.
Почему я говорил о том, что стоит заводить свои типы исключений – так вы проще сможете их выделить на стадии обработки. Представьте себе, что существуют пять причин, по которым может быть выброшено исключение, и во всех пяти случаях бросается java.lang.Exception . Вы же спятите разбираться, чем именно это исключение вызвано. А если это будет пять разных типов – тут уже проще простого. На каждый – свой блок catch .
И третье – что делать с иерархиями исключений. Пусть у вас метод может выбросить как IOException , так и Exception . Так вот, совершенно не все равно, в каком порядке будут стоять блоки catch , поскольку они обрабатываются ровно в той последовательности, как объявлены. И если первым будет catch(Exception ex) – до второго ( catch(IOException ioex) ) управление просто не дойдет. Компилятор об этом, конечно, предупредит, более того – это считается ошибкой. Тем не менее об этом стоит помнить.
Следующее, чего бы я хотел коснуться –
Перехват исключений, вызвавших завершение потока
При использовании нескольких потоков бывают ситуации, когда надо знать, как поток завершился. В смысле – если это произошло из-за исключения, то из-за какого именно. Для этой цели начиная с версии Java 5 существует специальный интерфейс – Thread.UncaughtExceptionHandler . Его реализацию можно установить нужному потоку с помощью метода setUncaughtExceptionHandler . Можно также установить обработчик по умолчанию с помощью статического метода Thread.setDefaultUncaughtExceptionHandler .
Интерфейс Thread.UncaughtExceptionHandler имеет один единственный метод – uncaughtException(Thread t, Throwable e) – в который передается экземпляр потока, завершившегося исключением, и экземпляр самого исключения. Восстановить работу потока, естественно, уже не удастся, но зафиксировать факт его ненормального завершения таким образом можно.
Следующее, о чем я хотел бы поговорить – сама конструкция try / catch / finally .
Конструкция try / catch / finally – тонкости
С блоком try , думаю, вопросов не возникает. С блоком catch – надеюсь, уже тоже нет. Остается блок finally . Что это, и с чем его едят?
Блок finally идет в самом конце конструкции try / catch / finally . Ключевая его особенность в том, что он выполняется всегда, вне зависимости от того, сработал catch или нет.
Зачем это нужно. Посмотрите вот на этот фрагмент кода:
try < Connection conn = DriverManager.getConnection("jdbc:mysql://localhost:3306/db"); Statement stmt = conn.createStatement(); ResultSet rs = stmt.executeQuery("select * from my_table"); rs.first(); while (rs.next()) < // do something > rs.close(); stmt.close(); conn.close(); > catch (SQLException ex) < // handle exception >
Казалось бы все в порядке. А что будет, если, например, при вызове rs.first() произойдет исключение? Да, оно обработается. Однако ни ResultSet , ни Statement , ни Connection закрыты не будут. Последствия весьма печальны – исчерпание открытых курсоров, соединений в пуле и т.п.
Можно, конечно, поместить этот же код и в блок catch . Однако дублировать код – не лучшая идея. Правильнее вынести код закрытия в блок finally , в этом случае он будет исполнен как в случае возникновения исключения, так и в случае, когда этого не происходит.
Рассмотрим еще один пример:
package test; /** * FinallyTest * * @author Eugene Matyushkin */ public class FinallyTest< public static int stringSize(Object s) < try < return s.toString().length(); > catch (Exception ex) < return -1; > finally < return 0; > > public static void main(String[] args)< System.out.println("stringSize(\"string\"): "+stringSize("string")); System.out.println("stringSize(null): "+stringSize(null); > >
Вопрос на засыпку – каков будет результат? Выполняем тест и получаем:
stringSize("string"): 0 stringSize(null): 0
Т.е. в обоих случаях результат будет одинаковый, причем не тот, которого можно было бы ожидать! Почему так происходит? В первом случае – из блока try должно вернуться значение 6 – длина переданной строки. Однако выполняется блок finally , в котором возвращается 0. В результате исходное значение теряется. Во втором случае – попытка вызвать toString() при переданном значении null приведет к исключению – NullPointerException . Это исключение будет перехвачено, т.к. является наследником Exception . Из блока catch должно вернуться значение -1, однако выполняется блок finally и возвращается опять-таки 0, а -1 – теряется!
Точно так же блок finally может вызвать потерю исключений. Посмотрите вот на этот пример:
package test; import java.io.IOException; /** * ExceptionLossTest */ public class ExceptionLossTest< public static void main(String[] args)< try < try < throw new Exception("a"); > finally < if (true) < throw new IOException("b"); > System.err.println("c"); > > catch (IOException ex) < System.err.println(ex.getMessage()); >catch (Exception ex) < System.err.println("d"); System.err.println(ex.getMessage()); > > >
Этот тест очень часто давался на интервью. И правильно отвечали единицы. Между тем – результатом его выполнения будет вывод в консоль b. И только. После инициации первого исключения – new Exception("a") – будет выполнен блок finally , в котором будет брошено исключение new IOException("b") . И именно это исключение будет поймано и обработано. Исходное же исключение теряется.
Хотелось бы затронуть еще один момент. В каких комбинациях могут существовать блоки try , catch и finally ? Понятно, что try – обязателен. Он может быть совместно с catch , либо с catch и finally одновременно. Отдельно try не используется. А есть ли еще варианты?
Есть. try может быть в паре с finally , без catch . Работает это точно так же – после выхода из блока try выполняется блок finally . Это может быть полезно, например, в следующей ситуации. При выходе из метода вам надо произвести какое-либо действие. А return в этом методе стоит в нескольких местах. Писать одинаковый код перед каждым return нецелесообразно. Гораздо проще и эффективнее поместить основной код в try , а код, выполняемый при выходе – в finally .
И последняя тема –
Отсутствие транзакционности
В самом начале я упоминал о том, что организовать утечку памяти при использовании исключений в конструкторах сложно. На самом деле – можно. Смотрим на пример.
package test; /** * PartialInitTest * * @author Eugene Matyushkin */ public class PartialInitTest< static PartialInitTest self; private int field1 = 0; private int field2 = 0; public PartialInitTest(boolean fail) throws Exception< self = this; field1 = 1; if (fail) < throw new Exception(); > field2 = 1; > public boolean isConsistent()< return field1 == field2; > public static void main(String[] args)< PartialInitTest pit = null; try < pit = new PartialInitTest(true); > catch (Exception ex)< // do nothing > System.out.println("pit: "+pit); System.out.println("PartialInitTest.self reference: "+PartialInitTest.self); System.out.println("PartialInitTest.self.isConsistent(): "+PartialInitTest.self.isConsistent()); > >
Итак, что тут происходит. В конструкторе мы присваиваем ссылку на созданный объект статической переменной. Дальше мы инициализируем одно поле и. бросаем исключение. Я это делаю намеренно, однако это может произойти и в результате выполнения кода конструктора. В методе main это исключение обрабатывается. Однако ссылка на объект – существует! В чем можно убедиться, выполнив приведенный код:
pit: null PartialInitTest.self reference: test.PartialInitTest@1e0bc08 PartialInitTest.self.isConsistent(): false
Переменная метода main равна null , как и положено. А вот статическая переменная self – нет. Через нее можно получить доступ к объекту, инициализация которого была прервана исключением. И объект этот, естественно, в неверном состоянии. Вот она – утечка памяти. Объект не будет удален до тех пор, пока на него есть ссылка.
Пример этот искуственный, но лишь до известной степени. Он говорит об очень важной особенности исключений:
Cвойством транзакционности исключения не обладают – действия, произведенные в блоке try до возникновения исключения, не отменяются поcле его возникновения.
И это необходимо учитывать. Применительно к приведенному примеру – стоит все операции, могущие привести к исключению, выполнять как можно раньше. Например, проверять переданные параметры сразу же. В некоторых случаях для отмены уже произведенных действий может пригодиться блок finally . А если очень надо где-то сохранить ссылку на создаваемый объект, причем сделать это необходимо в конструкторе – лучше всего оставить это напоследок, когда весь критический код уже выполнен.
Ну, вот и все. Думаю, большая часть этого материала вам была знакома. Во всяком случае, надеюсь на это. Моей целью было просто упорядочить информацию для тех, кто с исключениями пока еще знаком поверхностно. Всем спасибо!
Copyright © 2004-2013 Евгений Матюшкин aka Skipy (e-mail: skiрyskipy.ru)
Копирование и воспроизведение материалов этого сайта возможно только с согласия автора!
Ответы на вопросы на собеседование Java core (часть 3).
Все классы-исключения расширяют класс Throwable - непосредственное расширение класса object. 
У класса Throwable и у всех его расширений по традиции два конструктора:

Throwable о - конструктор по умолчанию;
Throwable (String message) - создаваемый объект будет содержать произвольное сообщение message.

Записанное в конструкторе сообщение можно получить затем методом getMessage (). Если объект создавался конструктором по умолчанию, то данный метод возвратит null. 
Метод toString возвращает краткое описание события, именно он работал в предыдущих листингах.
Три метода выводят сообщения обо всех методах, встретившихся по пути "полета" исключения:

printstackTrace() - выводит сообщения в стандартный вывод, как правило, это консоль;
printStackTrace(PrintStream stream) - выводит сообщения в байтовый поток stream;
printStackTrace(PrintWriter stream) - выводит сообщения в символьный поток stream.

У класса Throwable два непосредственных наследника - классы Error и Exception. Они не добавляют новых методов, а служат для разделения классов-исключений на два больших семейства - семейство классов-ошибок (error) и семейство собственно классов-исключений (exception).
Классы-ошибки, расширяющие класс Error, свидетельствуют о возникновении сложных ситуаций в виртуальной машине Java. Их обработка требует глубокого понимания всех тонкостей работы JVM. Ее не рекомендуется выполнять в обычной программе. Не советуют даже выбрасывать ошибки оператором throw. He следует делать свои классы-исключения расширениями класса Error или какого-то его подкласса.
Имена классов-ошибок, по соглашению, заканчиваются словом Error.
Классы-исключения, расширяющие класс Exception, отмечают возникновение обычной нештатной ситуации, которую можно и даже нужно обработать. Такие исключения следует выбросить оператором throw. Классов-исключений очень много, более двухсот. Они разбросаны буквально по всем пакетам J2SDK. В большинстве случаев вы способны подобрать готовый класс-исключение для обработки исключительных ситуаций в своей программе. При желании можно создать и свой класс-исключение, расширив класс Exception или любой его подкласс.
Среди классов-исключений выделяется класс RuntimeException - прямое расширение класса Exception. В нем и его подклассах отмечаются исключения, возникшие при работе JVM, но не столь серьезные, как ошибки. Их можно обрабатывать и выбрасывать, расширять своими классами, но лучше доверить это JVM, поскольку чаще всего это просто ошибка в программе, которую надо исправить. Особенность исключений данного класса в том, что их не надо отмечать в заголовке метода пометкой throws.
Имена классов-исключений, по соглашению, заканчиваются словом Exception.

Какие виды исключений в Java вы знаете, чем они отличаются?

Все исключительные ситуации можно разделить на две категории: проверяемые(checked) и непроверяемые(unchecked).
Все исключения, порождаемые от Throwable, можно разбить на три группы. Они определяются тремя базовыми типами: наследниками Throwable - классами Errorи Exception, а также наследником Exception - RuntimeException.
Ошибки, порожденные от Exception (и не являющиеся наследниками RuntimeException ), являются проверяемыми. Т.е. во время компиляции проверяется, предусмотрена ли обработка возможных исключительных ситуаций. Как правило, это ошибки, связанные с окружением программы (сетевым, файловым вводом-выводом и др.), которые могут возникнуть вне зависимости от того, корректно написан код или нет. Например, открытие сетевого соединения или файла может привести к возникновению ошибки и компилятор требует от программиста предусмотреть некие действия для обработки возможных проблем. Таким образом повышается надежность программы, ее устойчивость при возможных сбоях.
Исключения, порожденные от RuntimeException, являются непроверяемыми и компилятор не требует обязательной их обработки.
Как правило, это ошибки программы, которые при правильном кодировании возникать не должны (например, IndexOutOfBoundsException- выход за границы массива, java.lang.ArithmeticException- деление на ноль). Поэтому, чтобы не загромождать программу, компилятор оставляет на усмотрение программиста обработку таких исключений с помощью блоков try-catch.
Исключения, порожденные от Error, также не являются проверяемыми. Они предназначены для того, чтобы уведомить приложение о возникновении фатальной ситуации, которую программным способом устранить практически невозможно (хотя формально обработчик допускается). Они могут свидетельствовать об ошибках программы, но, как правило, это неустранимые проблемы на уровне JVM. В качестве примера можно привести StackOverflowError (переполнение стека), OutOfMemoryError (нехватка памяти).
Методы, код которых может порождать проверяемые исключения, должны либо сами их обрабатывать, либо в заголовке метода должно быть указано ключевое слово throws с перечислением необрабатываемых проверяемых исключений. На непроверяемые ошибки это правило не распространяется.
Переопределенный (overridden) метод не может расширять список возможных исключений исходного метода.

Что такое checked и unchecked Exception?

Checked исключения, это те, которые должны обрабатываться блоком catch или описываться в сигнатуре метода. Unchecked могут не обрабатываться и не быть описанными.


Похожие публикации:

Steam link что это
Женщина программист как морская свинка
Как работают в гугл
Что больше 500 гб или 1 тб