Чтение онлайн

Проблема потерянных исключений

К сожалению, реализация механизма исключений в 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), никаких проблем с возбуждением исключений нет.