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