Наследование и исключения в Java

Создание сложных распределенных систем редко обходится без наследования и обработки исключений. Следует знать два правила для проверяемых исключений при наследовании:

· переопределяемый метод в подклассе не может содержать в инструк­ции throws исключений, не обрабатываемых в соответствующем методе суперкласса;

· конструктор подкласса должен включить в свой блок throws все классы исключений или их суперклассы из блока throws конструк­тора суперкласса, к которому он обращается при создании объекта.

Первое правило имеет непосредственное отношение к расширяемости приложения. Пусть при добавлении в цепочку наследования нового класса его полиморфный метод включил в блок throws «новое» проверяемое исключение. Тогда методы логики пріложения, принимающие объект нового класса в качестве параметра и вызывающие данный полиморфный метод, не готовы обрабатывать «новое» исключение, так как ранее в этом не было необходимости. Поэтому при попытке добавления «нового» checked-исключения в полиморфный метод компилятор выдает сообщение об ошибке.

/* пример # 7 : полиморфизм и исключения: Stone.java: WhiteStone.java: BlackStone.java: StoneLogic.java */

package chapt08;

class Stone { //старый класс

public void build() throws FileNotFoundException {

/* реализация*/ }

}

class WhiteStone extends Stone {//старый класс

public void build() {

System.out.println("белый каменный шар");

}

}

public class StoneLоgic {//старый класс

public static void infoStone(Stone stone) {

try {

stone.build();//обработка IOException не предусмотрена

} catch(FileNotFoundException e) {

System.err.print("файл не найден");

}

}

}

class BlackStone extends Stone {//новый класс

public void build() throws IOException{//ошибка компиляции

System.out.println("черный каменный шар");

/* реализация*/

}

}

Если же при объявлении метода суперкласса инструкция throws присутствует, то в подклассе эта инструкция может вообще отсутствовать или в ней могут быть объявлены любые исключения, являющееся подклассами исключения из блока throws метода суперкласса

Второе правило позволяет защитить программиста от возникновения неизвестных ему исключений при создании объекта.

/* пример # 8 : конструкторы и исключения: FileInput.java: SocketInput.java */

package chapt08;

import java.io.FileNotFoundException;

import java.io.IOException;

class FileInput {//старый класс

public FileInput(String filename)

throws FileNotFoundException {

//реализация

}

}

class SocketInput extends FileInput {

//старый конструктор

public SocketInput(String name)

throws FileNotFoundException {

super(name);

//реализация

}

/старый конструктор

public SocketInput() throws IOException {

super("file.txt");

//реализация

}

/новый конструктор

public SocketInput(String name, int mode) {/*ошибка

компиляции*/

super(name);

//реализация

}

}

В приведенном выше случае компилятор не разрешит создать конструктор подкласса, обращающийся к конструктору суперкласса без корректной инструк­ции throws. Если бы это было возможно, то при создании объекта подкласса класса FileInput не было бы никаких сообщений о возможности генерации исключения, и при возникновении исключительной ситуации ее источник было бы трудно идентифицировать.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100