Обработка ошибок и исключения — различия между версиями
Sergej (обсуждение | вклад)  (→Так когда же нужно бросать ошибки?)  | 
				Sergej (обсуждение | вклад)   | 
				||
| Строка 16: | Строка 16: | ||
Нарушение контракта со стороны создателя метода - это, например, что-нибудь на подобии <tex>MethodNotImplementedYetException</tex>.  | Нарушение контракта со стороны создателя метода - это, например, что-нибудь на подобии <tex>MethodNotImplementedYetException</tex>.  | ||
Пользователь метода может нарушить контракт, например, таким способом: на вход <tex>Integer.parseInt(String)</tex> подать строку с буквами и по заслугам получить <tex>NumberFormatException</tex>  | Пользователь метода может нарушить контракт, например, таким способом: на вход <tex>Integer.parseInt(String)</tex> подать строку с буквами и по заслугам получить <tex>NumberFormatException</tex>  | ||
| + | |||
| + | == А что собственно бросать? ==  | ||
| + | Выбор не то чтобы сильно велик, но и не однозначен: <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>, как было написано выше, заставляет программиста-пользователя написать код для ее обработки или же описать метод как “вызывающий исключительную ситуацию”.  | ||
| + | С <tex>unchecked</tex> <tex> exception</tex> можно поступить по-разному. В случае с такими ошибками, пользователь сам решает, будет он обрабатывать эту ошибку, или же нет (компилятор не заставляет это делать).  | ||
| + | Можно написать следующее простое правило: если некоторый набор входящих в метод данных может привести к нарушению контракта, и вы считаете, что программисту-пользователю важно разобраться с этим (и что он сможет это сделать), описывайте метод с конструкцией <tex>throws</tex>, иначе бросайте <tex>unchecked</tex> <tex>exception.</tex>  | ||
Версия 20:51, 17 июня 2013
| Определение: | 
| Исключениями или исключительными ситуациями (состояниями) называются ошибки, возникшие в программе во время её работы. | 
Введение
В языке исключения и ошибки являются объектами. Когда метод вызывает (бросает - throws) исключительную ситуацию, он на самом деле работает с объектом. Но такое происходит не с любыми объектами, а только с теми, которые наследуются от
, и их наследников еще называют , а всех остальных наследников класса обязывает пользователя обработать ее (использую конструкцию .) или же отдать на откуп обрамляющим методам, в таком случае к декларации метода, который бросает проверяемое исключение, дописывают конструкцию , например
public Date parse(String source) throws ParseException { ... }
Так когда же нужно бросать ошибки?
На этот вопрос можно ответить просто: если в методе возможна ситуация, которую метод не в состоянии обработать самостоятельно, он должен “бросать” ошибку. Но ни в коем случае нельзя использовать исключительные ситуации для управления ходом выполнения программы. Чаще всего бросаются при нарушении контракта метода. Нарушение контракта со стороны создателя метода - это, например, что-нибудь на подобии . Пользователь метода может нарушить контракт, например, таким способом: на вход подать строку с буквами и по заслугам получить
А что собственно бросать?
Выбор не то чтобы сильно велик, но и не однозначен: , В подавляющем большинстве случаев вам не понадобится. Это в основном критические ошибки (например, ), с которыми пусть работает JVM. , как было написано выше, заставляет программиста-пользователя написать код для ее обработки или же описать метод как “вызывающий исключительную ситуацию”. С можно поступить по-разному. В случае с такими ошибками, пользователь сам решает, будет он обрабатывать эту ошибку, или же нет (компилятор не заставляет это делать). Можно написать следующее простое правило: если некоторый набор входящих в метод данных может привести к нарушению контракта, и вы считаете, что программисту-пользователю важно разобраться с этим (и что он сможет это сделать), описывайте метод с конструкцией , иначе бросайте
