====runtime exception====
Эти исключения обычно возникают в результате ошибок программирования, например, ошибки разработчика или неверное использование интерфейса приложения. Например, в случае выхода за границы массива метод бросит ''OutOfBoundsException''. Теоретически приложение может поймать это исключение, но разумнее исправить ошибку.
== Введение ==
В языке <tex>Java</tex> исключения <tex>(Exceptions)</tex> и ошибки <tex>(Errors)</tex> являются объектами. Когда метод вызывает (бросает - throws) исключительную ситуацию, он на самом деле работает с объектом. Но такое происходит не с любыми объектами, а только с теми, которые наследуются от <tex>Throwable.</tex>
[[Файл:exceptions==Обработка исключений==Код, который может бросить исключения оборачивается в try-throwableблок, после которого идут блоки catch и finally.gif]]
<tex>RuntimeException</tex>, <tex>Error</tex> и их наследников еще называют <tex>unchecked</tex> <tex>exception</tex>, а всех остальных наследников класса <tex>Exception -</tex> <tex>checked</tex> <tex> exception.</tex> <tex> Checked</tex> <tex> Exception</tex> обязывает пользователя обработать ее (использую конструкцию <tex> tryСatch-catch </tex>.) или же отдать на откуп обрамляющим методамблоки обрабатывают исключения, указанные в таком случае к декларации метода, который бросает проверяемое <tex>(checked)</tex> исключение, дописывают конструкцию <tex>throws</tex>качестве аргумента. Тип аргумента должен быть именем класса, например public Date parse(String source) throws ParseException { ..унаследованного от ''Throwable''. }
== Так когда же нужно бросать ошибки? ==На этот вопрос можно ответить простоКод из блока finally выполнится в любом случае: если в методе возможна ситуацияпри нормальном выходе из try, которую метод не в состоянии обработать самостоятельно, он должен “бросать” ошибку. Но ни в коем случае нельзя использовать исключительные ситуации для управления ходом выполнения программы.Чаще всего <tex>Exceptions</tex> бросаются после обработки исключения или при нарушении [[Программирование выходе по контракту|контракта]] методакоманде return.Нарушение контракта со стороны создателя метода - это, например, что-нибудь на подобии <tex>MethodNotImplementedYetException</tex>.Пользователь метода может нарушить контракт, например, таким способом: на вход <tex>IntegerБлок finally удобен для закрытия файлов и освобождения любых других ресурсов.parseInt(String)</tex> подать строку с буквами и по заслугам получить <tex>NumberFormatException</tex>
== А что собственно бросать? ==Выбор не то чтобы сильно велик, но и не однозначенNB: <tex>checked,</tex> <tex>unchecked</tex> <tex>(runtime)</tex>, <tex>unchecked</tex> <tex>(error).</tex>В подавляющем большинстве случаев <tex>Error</tex> вам не понадобится. Это в основном критические ошибки (например, <tex>StackOverflowError</tex>), с которыми пусть работает Если JVM.<tex>Checked</tex> <tex>Exceptions</tex>, как было написано выше, заставляет программиста-пользователя написать код для ее обработки выйдет во время выполнения кода из try или же описать метод как “вызывающий исключительную ситуацию”.С <tex>unchecked</tex> <tex> exception</tex> можно поступить по-разному. В случае с такими ошибкамиcatch, пользователь сам решает, будет он обрабатывать эту ошибку, или же нет (компилятор то finally блок может не заставляет это делать)выполниться.Можно написать следующее простое правило: если некоторый набор входящих в метод данных может привести к нарушению контрактаТакже, и вы считаетенапример, что программисту-пользователю важно разобраться с этим если (и что он сможет это сделать?)выполняющий try или catch код прерван, описывайте метод с конструкцией <tex>throws</tex>то блок finally может не выполниться, иначе бросайте <tex>unchecked</tex> <tex>exceptionдаже если приложение продолжает работать.</tex>
== Как обрабатывать? ==Обрабатывать ошибку лучше там, где она возникла. Если Код в данном фрагменте кода нет возможности принять решениеблоке finally должен быть максимально простым: например, что делать с исключениемесли внутри блока finally будет брошено какое-либо исключение или просто встретится оператор return, его нужно бросать дальше, пока не найдется нужный обработчик, либо поток выполнения программы не вылетит совсемброшенное в блоке try исключение (если таковое было брошено) будет забыто.
import java.io.IOException; public class intException extends Exception ExceptionTest { intException public static void main(String message[] args){ super(message); try { } } class Number try { int b; int division throw new Exception(int "a") throws intExceprion; } finally { if (a == 0) throw new intExceptionIOException("Division by zerob"); else return this.b / a; } } try catch (IOException ex) { int c = a System.err.println(ex.divisiongetMessage(b)); // Безопасное использование результата. } catch (intException eException ex) { System.err.println(ex.getMessage()); } // Обработка ошибки} }Также возможно делать несколько catch После того, как было брошено первое исключение - try {new Exception("a") - будет выполнен блок finally, в котором будет брошено исключение new IOException("b"), именно оно будет поймано и обработано. Результатом его выполнения будет вывод в консоль ''b''. Исходное исключение теряется. ==Исключения в Java7+==* обработка нескольких типов исключений в одном catch-блоке: // Действия } catch (*Exception eIOException|SQLException ex) {...} // Обработка исключения } В таких случаях параметры являются ''final'', следовательно, нельзя присвоить им любое значение в блоке catch (. *Exception e) {Try с ресурсами // Обработка исключения Ресурс {{---} finally { // Действия при выходе }Блок <tex> finally </tex> выполняется в независимости от выполнения <tex> catch </tex>это объект, который должен быть закрыт после завершения работы с ним.
