Ранее мы генерировали три исключения в методе setName ( ). Все три исключения использовали базовый класс Error. Приведем этот код снова:

if (newName. indexOfC «) == 0) {

// Имена не могут начинаться с пробела…

throw new ЕггогС»Invalid pet name specified.»); } else if (newName == «») {

throw new ErrorCPet name too short.»); } else if (newName. length > VirtualPet. maxNameLength) {

throw new ErrorCPet name too long.»);

}

В данном коде, чтобы провести различие между исключениями класса Virtual Pet и остальными исключениями в нашем приложении, мы использовали переменную message класса Error, которая, как уже известно, делает наши исключения неудобными для использования и может привести к появлению ошибок, вызванных человеческим фактором. Для отличия ошибок, относящихся к классу Virtual Pet, от других ошибок в нашем приложении лучше определить пользовательский подкласс класса Error с именем VirtualPetNameException, как показано в следующем коде:

// Код в файле VirtualPetNameException. as: package zoo {

public class VirtualPetNameException extends Error { public function VirtualPetNameException ( ) { // Передаем сообщение об ошибке в конструктор класса Error, которое // будет присвоено переменной message данного объекта ‘ superCInvalid pet name specified.»);

}

}

}

Теперь, когда у нас появился класс VirtualPetNameException, метод setName ( ) может генерировать свой собственный тип ошибки, как показано в следующем коде:

public function setName (newName:String):void { if (newName. indexOfС «) == 0) {

throw new VirtualPetNameException( ); } else if (newName == «») {

throw new VirtualPetNameException( ); } else if (newName. length > Virtual Pet. maxNameLength) {

throw new VirtualPetNameException( );

}

petName = newName;

}

Обратите внимание, что в предыдущем описании метода для всех трех исключительных ситуаций, относящихся к классу Virtual Ре t, генерируется один и тот же тип ошибки (VirtualPetNameException). Как разработчики класса VirtualPet мы столкнулись с проблемой определения степени детализации исключительных ситуаций. Мы должны решить не только то, в какой мере сообщения об ошибках класса

VirtualPet будут отличаться от других ошибок приложения, но и то, насколько эти ошибки будут отличаться друг от друга. У нас есть следующие варианты:

Вариант 1. Использовать один класс для исключительных ситуаций класса VirtualPet

В этом случае мы оставляем предыдущее описание метода s е tName ( ) как есть. Как вскоре станет известно, этот вариант позволяет отличать ошибки класса Vi rtual Ре t от других базовых ошибок в программе, однако мы не сможем отличить между собой три внутренние разновидности ошибок класса Virtual Pet (недопустимые данные, слишком короткое имя животного и слишком длинное имя животного).