Почему всегда нужно использовать FreeAndNil вместо Free

Это - собранные в кучу посты, которые потянулись за этим высказыванием.

Внимание! Пост направлен на обоснование моей точки зрения :D Просьба все негативные проклятия изливать где-то ещё ;)

Примечание: если вы плохо или совсем не понимаете, что такое указатели и/или объекты - рекомендую сначала прочитать эту статью.

Рассмотрим типичный код создания и удаления объекта, как его обычно приводят:

...
var
  SomeObj: TSomeClass;
...
  SomeObj := TSomeClass.Create;
  try
    ...
  finally
    SomeObj.Free;
  end;
...

Однако, я хочу показать, что вызова Free следует избегать, где это возможно, заменяя его на вызов FreeAndNil, вот так:

...
var
  SomeObj: TSomeClass;
...
  SomeObj := TSomeClass.Create;
  try
    ...
  finally
    FreeAndNil(SomeObj);
  end;
...

Заметьте, что речь идёт именно о замене Free на FreeAndNil везде. Не просто об использовании FreeAndNil, когда вы хотите проверять ссылку на nil, а именно - целиком и полностью везде. Т.е. не писать Free вообще никогда. Да, включая сценарии с локальными переменными.

Почему? Ну причина проста - нет никаких доводов так не делать (пожалуйста, дочитайте до конца). Зато есть доводы против использования Free в этих ситуациях.


Обычно "против" выдают такие доводы:

1. Ну, например: Free + nil не полностью эквивалентен FreeAndNil ("использовать FreeAndNil нужно аккуратно, потому что несмотря на название, там сначала происходит обнуление ссылки, а потом вызов Free. Если в деструкторе или методах из него вызванных нам ссылка нужна - приплыли. Например, поле класса. Мы его занулили, потом вызвали деструктор, а внутренний класс может что-то потребовать у внешнего, в т.ч. через это поле").

Это как раз плюс. Помогает отловить плохие ситуации. Потому что в описываемой ситуации идёт ссылка на объект через переменную, а не через Self. Заодно и избавимся от плохого стиля.

Кроме того, зачем это внешнему классу что-то требовать у своего поля в момент удаления этого поля? По-моему, это логическая ошибка в явном виде (обращение к объекту в момент его удаления, т.е. к частично-инициализированному объекту). И вот использование FreeAndNil как раз позволит отловить такие ситуации. Конечно, такая ситуация может быть заранее предусмотрена, но это совершенно некрасиво (шаг в сторону, любое изменение кода "не в тему" и ваш код перестанет работать). В любом случае, такая ситуация не плавающая и обнаружится сразу же. После чего вы спокойно вернёте Free на место.

2. Другое возможное возражение: привести пример оправданного использования FreeAndNil.

Не очень понятно, какого рода пример тут можно привести. Ведь использование FreeAndNil вместо Free - это же совершенно опциональное действие. Не считая запутанных примеров, один и тот же корректный код будет работать совершенно одинаково, что с Free, что с FreeAndNil.

FreeAndNil чем-то подобен ремням безопасности: если прогон прошёл в штатном режиме - они не пригодились. Но если ваш код где-то напутал в последовательности действий, то FreeAndNil (как и ремни безопасности) защитят вас от последствий. Обнулив ссылку, FreeAndNil поможет поймать левое обращение сразу же, на месте. Без него код мог продолжить своё выполнение и дать неверный результат без возбуждения ошибки. Это очень опасно.

Замечу, что, тем не менее FreeAndNil - это НЕ панацея, т.к. обращение к объекту может идти по нескольким переменным.

3. FreeAndNil тут излишен! (локальные переменные)

Локальную переменную могут потом сделать глобальной или частично-глобальной. FreeAndNil защитит нас от double-free. Просто Free - нет. Очень большое количество кода получается использованием copy-paste. Если стоит Free, то, скопировав код в другое место (где у переменной другая область видимости или она повторно используется) мы можем получить проблемы - с FreeAndNil таких проблем нет. Кроме того, если у вас большая процедура, то вы можете, не заметив, дважды использовать одну переменную (например - в цикле). Всегда используя FreeAndNil вы делаете свой код безопасным (к модификациям).

Ладно, это был слабый аргумент. А реальная причина - единообразие стиля. Удобно, когда везде написано FreeAndNil вместо помеси Free/FreeAndNil. И сам не запутаешься, когда что ставить (вам даже не надо думать: "ааа, здесь надо FreeAndNil или можно просто Free?!!").

Если в каких-то ситуациях FreeAndNil действительно излишен, то чего ж вы тогда не используете вызов Destroy? Ведь Free во многих ситуациях тоже излишен (я ни в коем разе не имел ввиду деструктор! Я сказал: во многих случаях. Случай удаления частично-инициализированного объекта в них, разумеется, не входит).

Заметьте, что в 99% кода на Delphi деструктор объектов не вызывается вообще! Нас уже приучили использовать вызов процедуры Free. А ведь когда-то народ, просто привыкший везде писать Destroy, тоже кричал: "зачем нам этот Free? Не нужен он тут! Где надо, я сам всё поставлю!". Ну и что? Пишем же мы сейчас все Free? (ладно, вообще-то этот пример - не факт, а моя фантазия, т.к. я уже начал подзабывать - как оно там на самом деле было, в те времена. Но могу легко себе это представить, и, вроде бы, это кажется правдоподобным :) ).

Ну так вот я агитирую за то, чтобы сделать ещё шаг вперёд: использовать FreeAndNil вместо Free. Ведь польза от перехода Free -> FreeAndNil гораздо больше, чем польза от уже случившегося перехода от Destroy к Free.

В первом случае мы получаем авто-защиту от плавающих ошибок (как я уже сказал, это не панацея, но, тем не менее, - существенный бонус). Во втором случае мы получили всего лишь возможность не писать явно if. Почему? Потому что если бы мы явно вызывали Destroy, вместо Free, то мы запустили бы деструктор с Self = nil, что немедленно привело бы к AV при первом же обращении к полю объекта. Ошибка совершенно не плавающая и легко отлавливается. Т.е. это чисто экономия времени на ввод, без дополнительных бонусов. Согласитесь, что бонус от первого перехода ("защита от ошибок") намного более существенен, чем бонус от второго ("короче писать"). Тем более, что вы можете не терять бонус "короче писать", введя процедуру с именем F, которая будет просто вызывать FreeAndNil. Или вы можете сделать шаблон LiveTemplate, как это сделал я.

4. Ещё один аргумент против: использование Free вместо Destroy, настоятельно рекомендуется самим Borland/CodeGear/Embarcadero, чего не скажешь про FreeAndNil.

Да, точно. Как будто эти рекомендации кто-то менял со времён динозавров :)

Я уже привёл аргументацию, что переход Free -> FreeAndNil имеет бОльшую ценность, чем переход Destroy -> Free. С учётом этого, аргумент отсутствия официального "добро" на FreeAndNil выглядит бледно.

5. Тем не менее, большинство людей, которые слышат о доводах к повсеместному использованию FreeAndNil вместо Free, утверждают, что это перебор.

Ну а почему?

Обычно ссылаются на силу привычки: "Free пишу на автомате, не задумываясь".

Кстати, второе возражение аналогичного плана - что Obj.Free короче, чем FreeAndNil(Obj); Это начинаются совсем уж мелкие придирки, потому что, даже если вы не имеете возможность использовать Code Templates, всегда можно ввести свою функцию F(Obj), которая будет просто вызывать FreeAndNil(Obj).

Но вот аргумент привычки - это достаточно серьёзный контр-довод.

Что я могу сказать? Хм, ну а вот у меня уже привычка писать FreeAndNil :) Тоже на автомате. Я себе даже Code Template на F + Tab забиндил: автоматом вставить FreeAndNil(Obj) и выделить Obj, чтобы я сразу впечатал имя переменной. Очень удобно, всего две кнопки, и скобки ставить не надо.

Этой статьёй я как раз хочу показать, что в данном случае имеются веские доводы к смене своих привычек. Конечно, ломать привычки - для этого нужен серьёзный повод. И вот тут мы подходим к...

6. Безопасность программирования.

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

Но это не верно. Вы не можете этого знать.

Представим, что в деструкторе объекта (объект-контейнер) мы удаляем объектное поле с помощью Free. В деструкторе этого поля вызывается виртуальный метод, который ничего не делает в базовом классе, а в каком-то далёком предке вызывает последовательность действий, которая приводит к вызову виртуального-же метода объекта-контейнера. Который, в свою очередь, в каком-нибудь далёком предке (ошибочно) обращается к нашему удаляемому полю. При этом, обращение проходит на ура, но общее состояние становится безвозвратно испорченным. Упс.

Почему я тут везде поставил виртуальные методы? Затем, чтобы нельзя было сказать: вот, смотрите, в моих классах нет нужды использовать FreeAndNil. Дело в том, что вы не можете этого знать! Вы-то создали чистую реализацию, а вот кто-нибудь другой создаст наследника, в котором неаккуратно вызовет в деструкторе какой-нибудь метод, приводящий (быть может далеко косвенно) к чтению уже удалённых или находящихся в процессе удаления объектов. FreeAndNil защитит вас от такой ситуации, Free - нет.

Далее, если продолжить мысль с вставкой FreeAndNil только в необходимые места - так ведь речь как-раз идёт о том, что это не всегда бывает видно. Взяв в привычку повсеместно писать FreeAndNil вы избавляете себя от этих проблем. И не надо ломать голову.

Проблема даже в том, что если вы привыкли использовать Free, то во большинстве случаем вам даже не придёт в голову задуматься: а не нужен ли здесь FreeAndNil? (хороший пример с деструктором объекта выше: вот могли ли вы предусмотреть эту ситуацию заранее?). И вот отсюда-то и лезут проблемы.

Как я уже сказал: FreeAndNil - это ремни безопасности. Осталось только это осознать.

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

_________________________________________________________

Итак.

Так зачем же медлить? Почему бы, начиная с сегодняшнего дня, везде (где это возможно) использовать FreeAndNil вместо Free? Если вы сделаете это своей привычкой - вы ничего не потеряете, а, наоборот, приобретёте немалые бонусы.

Я не единожды сталкивался с трудно выловимыми багами в чужом коде со сложной иерархией классов. Потратив несколько часов на бесплодные попытки найти источник проблем "в лоб", просто тупо заменив все Free на FreeAndNil, проблема находилась сразу же (но вот над решением проблемы приходилось ещу долго думать).

Тем не менее, я подозреваю, что большинство людей, даже если они согласятся с приведённой выше аргументацией, не будут ломать свои привычки только по той причине, что "кто-то там что-то сказал". Они не встречались с такой ситуацией - значит, её нет (пока гром не грянет...). Как я уже сказал, FreeAndNil - это ремни безопасности. Пока какой-нибудь косяк не ударит вас сильно по носу, вы, скорее всего, не будете его использовать. Но уж будьте уверены, что когда он ударит - это будет весьма болезненно. Вы можете потратить на отладку кучу времени.

Примечание: всё вышесказанное является только моим мнением. Я просто высказал точку зрения и привёл её аргументацию. Следовать этой рекомендации или нет - целиком ваше решение и я приму его, какое бы оно ни было. Если вы признали, что подобная точка зрения имеет право на жизнь - моя задача выполнена.

P.S. Насчёт "меньше печатать": создайте файл FreeAndNil.xml с таким содержанием:

<?xml version="1.0" encoding="utf-8" ?>

<codetemplate xmlns="http://schemas.borland.com/Delphi/2005/codetemplates"
    version="1.0.0">
 <template name="f" invoke="auto">
  <point name="var">
   <text>
    Variable
   </text>
   <hint>
    object to release
   </hint>
  </point>
  <description>
   release object and clear reference
  </description>
  <author>
   GunSmoker
  </author>
  <code language="Delphi" context="typedecl" delimiter="|"><![CDATA[FreeAndNil(|var|);]]>
  </code>
 </template>
</codetemplate>

И поместите его в папку C:\Users\UserName\Documents\RAD Studio\code_templates\Delphi\. Теперь для освобождения объекта достаточно набрать "f + пробел + имя-переменной".