Март 2011

Листинг 13.2. Использование оператора return в блоке try после оператора throw

public function changeFlow ( ):void { try {

throw new ErrorC’Test error.»); return;

} catch (e:Error) {

trace(«Caught: » + e. message); } finally {

trace(«Finally executed.»);

}

traceC’Last line of method.»);

}

// Вывод после вызова метода changeFlow( ): // Caught: Test error. // Finally executed. // Last line of method.

Листинг 13.3 демонстрирует использование оператора return в блоке catch. В данном случае return будет выполнен после завершения процесса обработки ошибки. При этом код, размещенный после инструкции try/catch/finally, выполнен не будет. Однако, как обычно, перед возвратом из метода будет выполнен блок fin а 11 у. В отличие от листингов 13.1 и 13.2 данный код является типичным в реальном сценарии, когда выполнение метода прекращается при возникновении ошибки.

Листинг 13.3. Использование оператора return в блоке catch

public function changeFlow ( ):void { try {

throw new ErrorC’Test error.»); } catch (e:Error) {

trace(«Caught: » + e. message);

return; } finally {

traceC’Finally executed.»);

}

traceC’Last line of function.»);

}

// Вывод после вызова метода changeFlow( ): // Caught: Test error. // Finally executed. ,

Из-за известной ошибки в приложении Flash Player 9 при выполнении кода из листингов 13.2 и 13.3 происходит обращение к несуществующей области стека. Корпорация Adobe планирует исправить эту проблему в следующей версии приложения Flash Player.

В листинге 13.4 показан оператор return в блоке finally. В данном случае он выполняется тогда, когда выполняется блок finally (как уже известно, выполнение блока finally происходит после завершения соответствующего блока try одним из следующих способов: без ошибок; с обработанной ошибкой; с необработанной ошибкой; в результате вызова операторов return, break или continue). Обратите внимание, что оператор return в листинге 13.4 предотвращает выполнение кода, размещенного после инструкции try/catch/ finally. Вы можете использовать подобную методику для завершения метода после выполнения блока кода независимо от того, было сгенерировано исключение или нет. При этом вся инструкция try/catch/finally обычно помещается внутрь условного оператора (иначе оставшаяся часть метода никогда не будет выполнена!).

Листинг 13.4. Использование оператора return в блоке finally

public function changeFlow ( ):void { try {

throw new ErrorC’Test error.»); } catch (e:Error) {

trace(«Caught: » + e. message); } finally {

trace(«Final! у executed.»);

return;

}

traceC’Last line of method.»); // He выполняется.

}

// Вывод после вызова метода changeFlow( ): Caught: Test error. Finally executed.

^ I Если оператор return в блоке finally вызывается после того, как был вызван оператор м$ 4 * return в соответствующем блоке try, вызов return в блоке finally отменяет предыдущий цу вызов return.

Обработка предопределенного исключения

В самом начале этой главы мы узнали, что с помощью инструкции try/catch/ finally можно обрабатывать как предопределенные, так и пользовательские ошибки. До настоящего момента все обрабатываемые нами ошибки были пользовательскими. Сейчас мы рассмотрим инструкцию try/catch/finally, обрабатывающую предопределенную ошибку.

Предположим, что мы создаем приложение для обмена текстовыми сообщениями, в котором при соединении с сервером данного приложения пользователю предлагается ввести номер порта. Мы присваиваем указанный номер порта переменной с именем user Port. После этого мы пытаемся подключиться к указанному порту,

используя класс Socket. В некоторых случаях установить соединение не получится из-за ограничений безопасности. Чтобы показать, что причиной неудачной попытки соединения являются ограничения безопасности, среда выполнения Flash генерирует исключение SecurityError. Таким образом, при попытке создать соединение мы помещаем соответствующий код в блок try. Если установить соединение не получится по причинам безопасности, мы отобразим для пользователя сообщение об ошибке, обозначив проблему, из-за которой возникла данная ошибка.

var socket:Socket = new Socket( ); try {

// Пытаемся подключиться к указанному порту socket. connect(«example. com». userPort); } catch (e:SecurityError) { // Код. расположенный здесь, отображает сообщение для пользователя

}

I Список причин, которые могут привести к ошибкам соединения сокета, можно найти м?’ л * в описании метода connect() класса Socket в справочнике по языку ActionScript корпо-цу рации Adobe.

События об ошибках в случае проблемных ситуаций. В предыдущем разделе мы рассмотрели, как обработать исключение, вызванное недопустимой попыткой установить соединение сокета. Однако не все сбойные ситуации в языке ActionScript приводят к генерации исключений. Информация о проблемах, возникающих асинхронно (то есть спустя некоторое время), передается через события об ошибках, а не через исключения. Например, если мы попытаемся загрузить файл, среда выполнения Flash в асинхронном режиме сначала должна проверить, существует ли запрашиваемый файл. Если этот файл не существует, среда Flash выполнит диспетчеризацию события IOErrorEvent. IO_ERROR. Чтобы обработать возникшую проблему, код, инициировавший операцию загрузки, должен зарегистрировать обработчик для события IOErrorEvent. IO ERROR. Если этого не произойдет, возникнет ошибка на этапе выполнения. Пример обработчика события об ошибке можно найти среди примеров в подразд. «Два дополнительных примера регистрации приемников событий» разд. «Основы обработки событий в ActionScript» гл. 12.

Впереди еще одна скучная работа

Исключения никогда не являлись самым эффектным аспектом программирования. Зачастую куда более забавно создавать программы, нежели выяснять, почему эти программы работают неправильно. Тем не менее обработка ошибок — это важная часть в разработке любой программы. В следующей главе мы рассмотрим еще одну похожую скучную тему, посвященную сборке мусора. Сборка мусора помогает предотвратить ситуацию, когда программа полностью исчерпывает системную память.

ПИВА 14

Сборка мусора

Всякий раз, когда программа создает объект, среда выполнения Flash сохраняет его в системной памяти (например, ОЗУ). По мере того как программа создает сотни, тысячи или даже миллионы объектов, объем памяти, занимаемой этой программой, постепенно увеличивается. Чтобы предотвратить полное исчерпывание системной памяти, Flash автоматически удаляет из нее объекты, когда программа перестает в них нуждаться. Процесс автоматического удаления объектов из памяти называется сборкой мусора.

Доступность объектов для сборки мусора

В программе на языке ActionScript любой объект становится доступным для процесса сборки мусора сразу после того, как он окажется недостижимым. Объект считается недостижимым, когда к нему невозможно обратиться прямо или косвенно хотя бы через один корневой элемент сборки мусора. К наиболее значимым корневым элементам сборки мусора в языке ActionScript можно отнести следующие:

? переменные, определенные на уровне пакета;

? локальные переменные в выполняющемся методе или функции;

? статические переменные;

? переменные экземпляра основного класса программы;

? переменные экземпляра объекта, находящегося в списке отображения среды выполнения Flash;

? переменные, находящиеся в цепочке областей видимости выполняющейся функции или метода.

Например, рассмотрим следующую версию класса VirtualZoo из нашей программы «Зоопарк». Обратите внимание, что в этой версии объект VirtualPet, создаваемый в конструкторе класса VirtualZoo, не присваивается переменной.

package { import flash. display. Sprite; import zoo.*;

public class VirtualZoo extends Sprite { public function VirtualZoo ( ) { new VirtualPet(«Stan»);

}

При выполнении конструктора класса VirtualZoo из предыдущего кода выражение new VirtualPet («Stan») создает новый объект класса VirtualPet. Однако обратиться к объекту после его создания невозможно, поскольку он не был присвоен никакой переменной. Как результат, созданный объект считается недостижимым и сразу же становится доступным для сборки мусора.

Теперь рассмотрим следующую версию класса VirtualZoo. Особое внимание уделите телу метода-конструктора, выделенного полужирным шрифтом:

package { import flash. display. Sprite; import zoo.*;

public class VirtualZoo extends Sprite { public function VirtualZoo ( ) { var pet:Virtual Pet * new Virtual Pet(«Stan»);

}

}

}

Как и раньше, при выполнении конструктора класса VirtualZoo из предыдущего кода выражение new VirtualPet («Stan») создает новый объект класса VirtualPet. Однако на этот раз созданный объект класса VirtualPet присваивается локальной переменной pet. В конструкторе класса VirtualZoo к объекту Vi rtual Ре t можно обратиться через эту локальную переменную, поэтому данный объект недоступен для сборки мусора. Тем не менее, как только выполнение конструктора VirtualZoo будет завершено, время жизни переменной pet истечет и обратиться к объекту VirtualPet будет невозможно. Как результат, объект считается недостижимым и становится доступным для сборки мусора.

Далее рассмотрим следующую версию класса VirtualZoo:

package { import flash. display. Sprite; import zoo.*;

public class VirtualZoo extends Sprite { private var pet:Virtual Pet;

public function VirtualZoo ( ) { pet = new Virtual Pet(«Stan»);

}

}

}

При выполнении конструктора класса VirtualZoo из предыдущего кода выражение new VirtualPet («Stan») снова создает объект класса Virtual Pet. Однако на этот раз созданный объект Vi rtual Ре t присваивается переменной экземпляра основного класса программы. По существу, этот объект считается достижимым и поэтому недоступен для сборки мусора.

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

package { import flash. display. Sprite; import zoo.*;

public class VirtualZoo extends Sprite { private var pet:Virtual Pet;

public function VirtualZoo ( ) { pet = new VirtualPetC’Stan»); pet = new Virtual Pet(«Tim»);

}

}

}

Как и раньше, первая строка конструктора из предыдущего кода создает объект класса VirtualPet и присваивает его переменной экземпляра pet. Однако вторая строка метода-конструктора из предыдущего кода создает еще один объект класса VirtualPet и тоже присваивает его переменной экземпляра pet. Вторая операция присваивания заменяет первое значение переменной pet (то есть животное с именем Stan) новым значением (то есть животным с именем Tim). Как результат, объект VirtualPet с именем Stan считается недостижимым и становится доступным для сборки мусора. Стоит отметить, что, если бы мы присвоили переменной pet значение null (или любое другое допустимое значение), как показано в следующем коде, объект VirtualPet с именем Stan также оказался бы недостижимым: pet = null;

Наконец, рассмотрим следующую версию класса VirtualZoo, в которой определены две переменные экземпляра petl и pet2:

package { import flash. display. Sprite; import zoo.*;

public class VirtualZoo extends Sprite { private var petl:Virtual Pet; private var pet2:Virtual Pet;

public function VirtualZoo ( ) { petl = new VirtualPetC’Stan»); pet2 = petl; petl = nul1; pet2 — nul1;

}

}

}

Как и раньше, первая строка конструктора из предыдущего кода создает объект класса VirtualPet; для удобства назовем его «Stan». Кроме того, первая строка присваивает объект «Stan» переменной petl. Затем вторая строка присваивает тот же объект переменной экземпляра pet2. После выполнения второй строки конструктора и перед выполнением третьей строки программа может обратиться

к объекту «Stan» как через переменную petl, так и через переменную pet2, поэтому данный объект недоступен для сборки мусора. Третья строка заменяет значение переменной petl значением null, так что объект «Stan» оказывается недоступен через эту переменную. Тем не менее к объекту 11 Stan» по-прежнему можно обратиться через переменную pet2, поэтому данный объект все еще недоступен для сборки мусора. Наконец, четвертая строка заменяет значение переменной pet2 значением null. Как результат, к объекту «Stan» больше нельзя обратиться через какую-либо переменную. «Бедный» объект «Stan» оказывается недостижимым и официально становится доступным для сборки мусора.

В языке ActionScript существует два особых случая, когда являющийся достижимым объект становится доступным для сборки мусора. Соответствующую информацию можно найти в разд. «Приемники событий и управление памятью» гл. 12 и в описании класса Dictionary справочника по языку ActionScript корпорации Adobe.

Алгоритм поэтапных пометок и вычищений

В предыдущем разделе рассказывалось, что объект становится доступным для сборки мусора (автоматического удаления из памяти) в тот момент, когда он оказывается недостижимым. Однако мы так и не выяснили, когда недостижимые объекты удаляются из памяти. В идеальном мире объекты должны удаляться из памяти сразу после того, как они оказались недостижимыми. Однако на практике незамедлительное удаление недостижимых объектов отнимает очень много времени и приводит к тому, что большинство нетривиальных программ выполняется медленно или вообще не отвечает на запросы. Соответственно среда выполнения Flash не удаляет недостижимые объекты из памяти незамедлительно. Вместо этого, она ищет и удаляет недостижимые объекты периодически, в процессе выполнения циклов сборки мусора.

Стратегия удаления недостижимых объектов языка ActionScript называется сборкой мусора с использованием алгоритма поэтапных пометок и вычищений. Рассмотрим, как это работает.

После запуска среда Flash просит операционную систему оставить, или выделить, произвольный объем памяти, в которой будут храниться объекты выполняемой в настоящий момент программы. По мере выполнения программы объекты накапливаются в памяти. В любой момент времени некоторые объекть программы являются достижимыми, а другие могут оказаться недостижимыми Если программа создаст достаточное количество объектов, среда выполнение Flash в конечном счете решит выполнить цикл сборки мусора. В процессе выполнения цикла все объекты, находящиеся в памяти, проверяются на «достижимость». В результате все достижимые объекты помечаются и продолжают храниться в памяти, а все недостижимые объекты вычищаются (удаляются^

из памяти. Однако в большой программе проверка объектов на достижимость может оказаться достаточно длительной. Соответственно среда Flash разбивает циклы сборки мусора на небольшие части, или приращения, которые включаются в процесс выполнения программы. Кроме того, среда выполнения Flash использует механизм отложенного подсчета ссылок для повышения производительности процесса сборки мусора. Информацию о механизме отложенного подсчета ссылок можно найти в статье «The Memory Management Reference: Beginner’s Guide: Recycling» по адресу http://www. memorymanagement. org/articles/ recycle. html#reference. deferred.

В языке ActionScript циклы сборки мусора обычно запускаются тогда, когда объем памяти, необходимый для хранения объектов программы, достигает объема памяти, выделенного среде Flash. Однако ActionScript не дает никакой гарантии относительно времени запуска циклов сборки мусора. Более того, программист не может заставить среду Flash выполнить цикл сборки мусора.

Намеренное освобождение объектов

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

Тем не менее, хотя программа и не может самостоятельно удалить объект из системной памяти, она по крайней мере может сделать этот объект доступным для удаления, устранив все ссылки на него. Чтобы устранить все ссылки на объект, мы должны вручную удалить этот объект из любых массивов, содержащих его, и присвоить значение null (или другое подходящее значение) всем переменным, ссылающимся на него.

Тот факт, что объект является доступным для сборки мусора, вовсе не означает, что он будет незамедлительно удален из памяти. Среда выполнения Flash просто получает разрешение на удаление этого объекта, когда (и если) запустится цикл сборки мусора.

Стоит отметить, однако, что создание и последующее удаление объектов из памяти зачастую является менее эффективным решением, чем повторное использование существующих объектов.

^ I Когда это возможно, вы должны стараться повторно использовать существующие объ-м?; 4 „ екты, а не удалять их.

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

package { import flash. display. Sprite: import zoo.*;

public class VirtualZoo extends Sprite { private var pet:Virtual Pet;

public function VirtualZoo ( ) { pet = new VirtualPetC’Stan»): pet. eat(new Applet )); pet. eat(new Apple( )); pet. eat(new Apple( )); pet. eat(new Apple( )); pet. eat(new Apple( ));

}

}

}

Обратите внимание, что при каждом кормлении животного предыдущий код создает новый экземпляр класса Apple и передает этот экземпляр в метод eat ( ). Всякий раз, когда завершается выполнение метода eat ( ), все ссылки на переданный в этот метод экземпляр класса Apple теряются, поэтому данный экземпляр становится доступным для сборки мусора. Теперь представьте, что произойдет, если мы скормим животному 1000 объектов класса Apple. Затраты нашей программы на обработку данных будут включать не только затраты на создание объектов класса Apple, но и затраты на их удаление из памяти в процессе сборки мусора. Чтобы минимизировать подобные затраты, лучше создать один повторно используемый объект класса Apple и применять его при каждом кормлении животного яблоком. Следующий код демонстрирует процесс пятикратного кормления животного одним и тем же объектом класса Apple:

package { import flash. display. Sprite: import zoo.*:

public class VirtualZoo extends Sprite { private var pet-.Virtual Pet: private var apple:Apple;

public function VirtualZoo ( ) { pet = new VirtualPetC’Stan»): apple = new Apple( );

pet. eat(apple); pet. eat(apple); pet. eat(apple); pet. eat(apple); pet. eat(apple);

}

}

}

К затратам предыдущего кода можно отнести затраты на создание единственного объекта. При этом не будет вообще никаких затрат на сборку мусора. Этот подход гораздо более эффективен по сравнению с предыдущим подходом, заключавшимся в создании нового объекта класса Apple и его последующем удалении для каждого вызова метода eat ( )!

Деактивация объектов

Как уже известно, удаление всех ссылок на объект делает его доступным для сборки мусора. Тем не менее даже после этого объект продолжает существовать в памяти до тех пор, пока среда выполнения Flash не решит «смести» его в одном из циклов сборки мусора. С того момента, как объект становится доступным для сборки мусора, и до того, как он фактически будет удален из системной памяти, данный объект продолжает получать события и, в случае объектов класса Function, может по-прежнему вызываться функцией setlnterval ( ).

Например, представьте приложение для демонстрации изображений в режиме слайд-шоу, которое использует класс ImageLoader для загрузки изображений с сервера через определенные интервалы времени. Код класса ImageLoader выглядит следующим образом:

package { import flash. events.*: import flash. utils.*:

public class ImageLoader { private var loadlnterval:int;

public function ImageLoader (delay:int = 1000) { loadlnterval = setlnterval(loadlmage. delay);

}

public function loadlmage ( ):void { traceC’Now loading image…»); // Код загрузки изображения // здесь не приводится

}

}

}

Теперь представьте, что основной класс приложения SlideShow реализует функциональность для запуска и остановки слайд-шоу. Для запуска слайд-шоу класс SlideShow создает экземпляр класса ImageLoader, управляющего процессом загрузки изображений. Экземпляр класса ImageLoader сохраняется в переменной экземпляра imgLoader, как показано в следующем коде: «

imgLoader = new ImageLoader( );

Для остановки или приостановки слайд-шоу класс SlideShow удаляет ссылку на экземпляр класса ImageLoader, как показано в следующем коде:

imgLoader = null;

Когда переменной imgLoader присваивается значение null, экземпляр класса ImageLoader становится доступным для сборки мусора. Тем не менее, до тех пор пока этот экземпляр не будет фактически удален из системной памяти, операция загрузки в экземпляре ImageLoader, реализованная на базе функции setlnterval ( ), будет регулярно выполняться.

Это демонстрирует следующий очень простой класс. Он создает экземпляр класса ImageLoader и сразу же удаляет ссылку на созданный экземпляр. Но даже после того, как переменной imgLoader присвоено значение null, сообщение «Now loading image…» продолжает появляться в окне для отладки с интервалом один раз в секунду.

package { import flash. display.*;

public class SlideShow extends Sprite { private var imgLoader:ImageLoader; public function SlideShow ( ) {

// Создаем экземпляр класса ImageLoader и сразу же удаляем ссылку

// на созданный экземпляр

imgLoader = new ImageLoader( );

imgLoader = null:

}

}

}

Если объем памяти, который необходим приложению для демонстрации изображений в режиме слайд-шоу, никогда не достигнет уровня, достаточного для запуска цикла сборки мусора, операция загрузки в экземпляре класса ImageLoader, реализованная на базе функции set I nterval ( ), будет выполняться бесконечно долго. Ненужное выполнение кода в «заброшенном» экземпляре класса ImageLoader тратит впустую системные и сетевые ресурсы и может привести к появлению нежелательных побочных эффектов в программе.

Чтобы избежать ненужного выполнения кода в «заброшенных» объектах, программа должна всегда деактивировать объекты перед тем, как избавиться от них. Деактивация объекта означает его перевод в нерабочее состояние, когда программа больше не может воспользоваться этим объектом для выполнения кода. Например, чтобы деактивировать объект, мы могли бы выполнить одно из перечисленных далее действий или же все действия сразу:

? отменить регистрацию методов объекта для событий;

? остановить все таймеры и интервалы;

? остановить воспроизводящую головку временных шкал (для экземпляров клипов, созданных в среде разработки Flash);

? деактивировать любые объекты, которые станут недостижимыми после того, как сам объект станет недостижимым.

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

Например, наш предыдущий класс ImageLoader должен определить метод, останавливающий внутренний интервал. Сейчас добавим подобный метод и назовем его dispose ( ). Имя выбрано произвольно; с таким же успехом мы могли бы присвоить данному методу имя kill ( ), destroy ( ), die ( ), clean ( ), disable ( ), deactivate ( ) или любое другое имя. Рассмотрим этот код:

package { import flash. events.*; import flash. utils.*;

public class ImageLoader { private var loadlnterval:int;

public function ImageLoader (delay;int = 1000) { loadlnterval =-setlnterval (loadlmage. delay);

}

public function loadlmage ( ):void { traceC’Now loading image…»); // Код загрузки изображения не приводится

}

public function dispose ( ):void { clearlnterval(loadlnterval);

}

}

}

Любой код, создающий экземпляр класса ImageLoader, должен в дальнейшем вызвать метод ImageLoader. dispose ( ) перед тем, как избавиться от этого экземпляра, как показано в следующем коде:

package { import flash. display.*;

public class SlideShow extends Sprite { private var imgLoader:ImageLoader; public function SlideShow ( ) {

// Создаем и сразу же избавляемся от экземпляра класса ImageLoader

imgLoader = new ImageLoader( );

imgLoader. dispose( );

imgLoader = null;

}

}

Сборка мусора в действии

В листинге 14.1 показана очень простая программа, демонстрирующая сборку мусора в действии. Программа создает объект класса Sprite, многократно отображающий сообщение в консоли для отладочной информации. Поскольку объект Sprite достижим только через локальную переменную, он становится доступным для сборки мусора сразу после завершения конструктора основного класса программы. При этом в программе также запущен таймер, который многократно создает объекты, занимая системную память. Когда объем потребленной памяти превысит допустимое значение, запустится сборщик мусора. В процессе сборки

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