51
} finally {
System.out.println("finally в первом блоке try"):
}
}
} /^Output-
Входим в первый блок try Входим во второй блок try finally во втором блоке try Перехвачено FourException в первом блоке try finally в первом блоке try *///:-
Блок finally также исполняется при использовании команд break и continue. Заметьте, что комбинация finally в сочетании с break и continue с метками снима¬ет в Java всякую необходимость в операторе goto.
Использование finally с return
Поскольку секция finally выполняется всегда, важные завершающие действия будут выполнены даже при возврате из нескольких точек метода:
//• excepti ons/Multi pleReturns java import static net.mindview util Print.*;
public class MultipleReturns {
public static void f(int i) {
pri nt("Инициализация. требующая завершения"), try {
print("Точка 1"), if(i == 1) return, print("Точка 2"); if(i == 2) return, print("Точка 3"), if(i == 3) return, print("Конец"), return; } finally {
ргШС'Завершение"),
}
}
public static void main(String[] args) { for (int i =1, i <=4; i++) f(i).
}
} /* Output;
Инициализация, требующая завершения
Точка 1
Завершение
Инициализация, требующая завершения Точка 1 Точка 2 Завершение
Инициализация, требующая завершения
Точка 1
Точка 2
Точка 3
Завершение
Инициализация, требующая завершения
Точка 1
Точка 2
Точка 3
Конец
Завершение *///;-
Из выходных данных видно, что выполнение finally не зависит от того, в ка¬кой точке защищенной секции была выполнена команда return.
Проблема потерянных исключений
К сожалению, реализация механизма исключений в Java не обошлась без изъяна. Хотя исключение сигнализирует об аварийной ситуации в программе и никогда
Использование finally с return 335
не должно игнорироваться, оно может быть потеряно. Это происходит при ис¬пользовании finally в конструкции определенного вида:
//: exceptions/LostMessage.java // Как теряются исключения.
class VeryImportantException extends Exception { public String toStringO {
return "Очень важное исключение!";
}
}
class HoHumException extends Exception { public String toStringO {
return "Второстепенное исключение";
}
}
public class LostMessage {
void fO throws VerylmportantException {
throw new VerylmportantExceptionO;
}
void disposeO throws HoHumException { throw new HoHumExceptionO;
}
public static void main(String[] args) { try {
LostMessage 1m = new LostMessageO; try {
lm.fO; } finally {
lm. disposeO; } catch(Exception e) {
System.out.println(e);
}
}
} /* Output:
Второстепенное исключение *///:-
В выводе нет никаких признаков VerylmportantException, оно было просто за¬мещено исключением HoHumException в предложении finally. Это очень серьез¬ный недочет, так как потеря исключения может произойти в гораздо более скрытой и трудно диагностируемой ситуации, в отличие от той, что показана в примере. Например, в С++ подобная ситуация (возбуждение второго исключе¬ния без обработки первого) рассматривается как грубая ошибка программиста. Возможно, в новых версиях Java эта проблема будет решена (впрочем, любой метод, способный возбуждать исключения — такой, как dispose() в приведенном примере — обычно заключается в конструкцию try-catch).
Еще проще потерять исключение простым возвратом из finally:
И: exceptions/ExceptionSi1encer.java
public class ExceptionSilencer {
public static void main(String[] args) { try {
throw new RuntimeExceptionO: } finally {
// Команда 'return' в блоке finally // прерывает обработку исключения return;
}
}
} ///.-
Запустив эту программу, вы увидите, что она ничего не выводит — несмотря на исключение.
Ограничения при использовании исключений
В переопределенном методе можно возбуждать только те исключения, которые были описаны в методе базового класса. Это полезное ограничение означает, что программа, работающая с базовым классом, автоматически сможет работать и с объектом, произошедшим от базового (конечно, это фундаментальный прин¬цип ООП), включая и исключения.
Следующий пример демонстрирует виды ограничений (во время компиля¬ции), наложенные на исключения:
//: exceptions/Stormylnning java // Переопределенные методы могут возбуждать только // исключения, описанные в версии базового класса, // или исключения, унаследованные от исключений // базового класса.
class BaseballException extends Exception {} class Foul extends BaseballException {} class Strike extends BaseballException {}
abstract class Inning {
public InningO throws BaseballException {} public void event О throws BaseballException { // Реальное исключение не возбуждается
}
public abstract void atBatO throws Strike. Foul;
public void walkO {} // He возбуждает контролируемых исключений
}
class StormException extends Exception {} class RainedOut extends StormException {} class PopFoul extends Foul {}
interface Storm {
public void event() throws RainedOut; public void rainHardO throws RainedOut;
}
public class Stormylnning extends Inning implements Storm { // Можно добавлять новые исключения для конструкторов. // но нужно учитывать и исключения базового конструктора; public StormyInning()
throws RainedOut. BaseballException {}
public StormyInning(String s)
throws Foul. Baseball Exception {} // Обычные методы должны соответствовать базовым: //! void walkO throws PopFoul {} // Ошибка компиляции // Интерфейс не МОЖЕТ добавлять исключения к // существующим методам базового класса: //! public void event О throws RainedOut {} // Если метод не был определен в базовом // классе, исключение допускается, public void rainHardO throws RainedOut {} // Метод может не возбуждать исключений вообще. // даже если базовая версия это делает: public void eventО {} // Переопределенные методы могут возбуждать // унаследованные исключения: public void atBatO throws PopFoul {} public static void main(String[] args) { try {
Stormy Inning si = new Stormy I nningO; si atBatO: } catch(PopFoul e) {
System.out.println("Pop foul"); } catch(RainedOut e) {
System.out printlnCRained out"): } catch(BaseballException e) {
System.out.println("Обобщенное исключение ");
}
// Strike не возбуждается в производной версии, try {
// Что произойдет при восходящем преобразовании? Inning i = new StormylnningO: i. atBatO:
// Необходимо перехватывать исключения из // базовой версии метода: } catch(Strike е) {
System.out.println("Strike"); } catch(Foul e) {
System.out.println("Foul"): } catch(RainedOut e) {
System.out.println("Rained out"): } catch(BaseballException e) {
System.out.println("Обобщенное исключение"):
}
}
} III-
В классе Inning и конструктор, и метод event() объявляют, что будут возбуж¬дать исключения, но в действительности этого не делают. Это допустимо, по¬скольку подобный подход заставляет пользователя перехватывать все виды ис¬ключений, которые потом могут быть добавлены в переопределенные версии метода event(). Данный принцип распространяется и на абстрактные методы, что и показано для метода atBat().
Интерфейс Storm интересен тем, что содержит один метод (event()), уже опре¬деленный в классе Inning, и один уникальный. Оба метода возбуждают новый тип исключения RainedOut. Когда класс Stormylnning расширяет Inning и реализует интерфейс Storm, выясняется, что метод event() из Storm не способен изменить тип исключения для метода event() класса Inning. Опять-таки это вполне разум¬но, так как иначе вы бы никогда не знали, перехватываете ли нужное исключе¬ние в случае работы с базовым классом. Конечно, когда метод, описанный в ин¬терфейсе, отсутствует в базовом классе (как rainHard()), никаких проблем с возбуждением исключений нет.
Метод StormyInning.walk() не компилируется из-за того, что он возбуждает исключение, тогда как Inning.walk() такого не делает. Если бы это позволялось, вы могли бы написать код, вызывающий метод Inning.walk() и не перехватываю¬щий никаких исключений, а потом при подстановке объекта класса, производ¬ного от Inning, возникли бы исключения, нарушающие работу программы. Таким образом, принудительно обеспечивая соответствие спецификаций исключений в производных и базовых версиях методов, Java добивается взаимозаменяемо¬сти объектов.
Переопределенный метод event() показывает, что метод производного класса может вообще не возбуждать исключений, даже если это делается в базовой версии. Опять-таки это нормально, так как не влияет на уже написанный код — подразумевается, что метод базового класса возбуждает исключения. Аналогич¬ная логика применима для метода atBat(), возбуждающего исключение PopFoul, производное от Foul, которое возбуждается базовой версией atBat(). Итак, если вы пишете код, работающий с Inning и вызывающий atBat(), то он должен пере¬хватывать исключение Foul. Так как PopFoul наследует от Foul, обработчик ис¬ключения для Foul перехватит и PopFoul.
Последний интересный момент встречается в методе main(). Мы видим, что при работе именно с объектом Stormylnning компилятор заставляет перехваты¬вать только те исключения, которые характерны для этого класса, но при восхо¬дящем преобразовании к базовому типу компилятор заставляет перехватывать исключения из базового класса. Все эти ограничения значительно повышают ясность и надежность кода обработки исключений .
Хотя компилятор заставляет описывать исключения при наследовании, спе¬цификация исключений не является частью объявления (сигнатуры) метода, которое состоит только из имени метода и типов аргументов. Соответственно, нельзя переопределять методы только по спецификациям исключений. Вдоба¬вок, даже если спецификация исключения присутствует в методе базового класса, это вовсе не гарантирует его существования в методе производного класса. Данная практика сильно отличается от правил наследования, по кото¬рым метод базового класса обязательно присутствует и в производном классе. Другими словами, «интерфейс спецификации исключений» для определенного метода может сузиться в процессе наследования и переопределения, но никак не расшириться — и это прямая противоположность интерфейсу класса во вре¬мя наследования.
Конструкторы
При программировании обработки исключений всегда спрашивайте себя: «Ес¬ли произойдет исключение, будет ли все корректно завершено?» Чаще все идет более или менее безопасно, но с конструкторами возникает проблема. Конст¬руктор приводит объект в определенное начальное состояние, но может начать выполнять какое-либо действие — такое как открытие файла — которое не бу¬дет правильно завершено, пока пользователь не освободит объект, вызвав спе¬циальный завершающий метод. Если исключение произойдет в конструкторе, эти финальные действия могут быть исполнены ошибочно. А это означает, что при написании конструкторов необходимо быть особенно внимательным.
Казалось бы, блок finally решает все проблемы. Но в действительности все сложнее — ведь finally выполняется всегда, и даже тогда, когда завершающий код не должен активизироваться до вызова какого-то метода. Если сбой в кон¬структоре произойдет где-то на середине, может оказаться, что часть объекта, освобождаемая в finally, еще не была создана.
В следующем примере создается класс, названный InputFile, который откры¬вает файл и позволяет читать из него по одной строке. Он использует классы FileReader и BufferedReader из стандартной библиотеки ввода/вывода Java, кото¬рая будет изучена далее, но эти классы достаточно просты, и у вас не возникнет особых сложностей при работе с ними:
// exceptions/InputFile java // Специфика исключений в конструкторах import java io *.
public class InputFile {
private BufferedReader in,
public InputFi1eCString fname) throws Exception { try {
in = new BufferedReader(new FileReader(fname)); // Остальной код, способный возбуждать исключения } catch(FileNotFoundException e) {
System out рппШС'Невозможно открыть " + fname); // Файл не открывался, поэтому не может быть закрыт throw е; } catch(Exception е) {
// При других исключениях файл должен быть закрыт try {
in.closeO; } catch(IOException e2) {
System out.println("in.close() исполнен неудачно");
}
throw e; // Повторное возбуждение } finally {
// He закрывайте файл здесь!!!
}
}
public String getLineO { String s, try {
s = in. readLine(); продолжение & } catch(IOException е) {
throw new RuntimeExceptionC'readLineO исполнен неудачно");