Когда вы открываете какое-то устройство файл или выделяете память то всегда нужно освобождать выделенные ресурсы. В языке Java есть специальные "сборщики мусора", которые сами убирают все ненужное, а в Delphi и С++ этого нет, и поэтому освобождать ресурсы надо самостоятельно.

Если выделить программе большой объем памяти и не освободить его, то весь этот объем полезного пространства будет недоступен системе. Допустим, что мы выделяем 100 Кбайт и не освобождаем их. Это не так много, и во времена компьютеров с сотнями мегабайтов памяти какие-то 100 из них не станут проблемой. А что, если пользователь запустит программу 10 раз? Вот тут уже происходит утечка в 1 Мбайт.

Неиспользуемые страницы памяти ОС может выгружать на диск в файл "подкачки". Неосвобожденные участки памяти не используются и помещаются в файл "подкачки". Через некоторое время память компьютера может "замусориться", и понадобится перезагрузка. Не забывайте, что файл "подкачки" расположен на диске, который не резиновый, и на нем тоже может закончиться место.

Некоторые ресурсы ОС вес же может закрывать за нас, даже если мы забыли об этом. К таким ресурсам относятся файлы. Если вы забыли закрыть их, то при выходе из программы ОС освободит блокировку.

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

Открытие файла: Обработка: Закрытие файла:

Если на этапе обработки произошла ошибка, то выполнение процедуры прекратится. Указатель останется неосвобожденным, а файл может остаться открытым и заблокированным для работы из других приложений до тех пор, пока программа не закроется.

Чтобы избежать этого эффекта, вы должны использовать код следующего вида: Открытие файла:

Проверка на действительность открытого файла: try

Обработка: finally

Закрытие файла: end:

При такой конструкции кода, даже если во время обработки произойдет ошибка, будет выполнен блок finally, в котором закрывается файл и освобождаются ресурсы.

То же самое относится и к памяти. После выделения необходимого блока обязательно проверьте правильность указателя и поместите блок try. .finally.

Проверка доступности ресурса должна осуществляться только до блока try.. fi -nal 1 у. Допустим, что вы не проверяете или делаете проверку доступности уже в блоке try.. finally. В этом случае если ресурс не был выделен, то генерируется ошибка и управление переходит в блок finally. Здесь мы пытаемся освободить ресурс, который не был выделен, и снова возникает ошибка

При использовании try.. f i nail у проверка доступности ресурса должна присутствовать обязательно. Представим, что ее вообще нет В этом случае если во время открытия файла произошла ошибка, то программа продолжит выполняться и войдет в блок try. При первом же обращении к переменной, которая должна указывать на файл, произойдет ошибка и управление будет передано блоку final 1у. А здесь у нас закрытие файла, который даже не открыт, поэтому снова возникает исключительная ситуация.

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

1.6.2. Проверка доступности ресурсов || Оглавление || 1.6.4. Обработка ошибок


Delphi в шутку и всерьез: что умеют хакеры



Новости за месяц

  • Декабрь
    2021
  • Пн
  • Вт
  • Ср
  • Чт
  • Пт
  • Сб
  • Вс
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31