Блог

Как среда CLR обрабатывает локальные переменные с областью действия функции в случае возникновения исключения. обязательно ли использовать блок finally или переменная удаляется, как только поток покидает функцию

ниже приведен небольшой пример

     protected void FunctionX()
    {
        List<Employee> lstEmployees;
        try
        {
           lstEmployees= new List<Employee>();
           int s =  lstEmployees[1].ID; // code intended to throw exception
        }
        catch (Exception ex)
        {
            ManageException(ex, ShowMessage); //exception is thrown here
        }
        finally { lstEmployees= null; } // Is the finally block required to make sure the list is cleaned
    }
  

Чтобы ответить на ваш конкретный вопрос, нет, finally указанный вами блок не требуется.

Присвоение null ссылочной переменной фактически ничего не делает, поскольку сборка мусора недетерминирована. В качестве упрощенного объяснения, время от времени сборщик мусора проверяет объекты в куче, чтобы определить, есть ли какие-либо активные ссылки на них (это называется «внедрением»). Если нет активных ссылок, то эти ссылки подходят для сборки мусора.

Ваше присвоение null не требуется, поскольку после завершения функции lstEmployees переменная выпадет из области действия и больше не будет считаться активной ссылкой на экземпляр, который вы создаете в своем try блоке.

Есть определенные типы (оба внутри .NET и в библиотеках сторонних производителей), которые реализуют IDisposable интерфейс и предоставляют некоторые детерминированные процедуры очистки с помощью Dispose() функции. При использовании этих типов вы должны всегда вызывать Dispose() , когда закончите с типом. В случаях, когда время жизни экземпляра не должно превышать время жизни функции, вы можете использовать using() { } блок, но это требуется только в том случае, если тип реализует, IDisposable что List<T> (как вы использовали в своем примере) не выполняется.

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

Если у вашего объекта есть дескриптор неуправляемого ресурса, выполните эту очистку.

Некоторые другие ответы здесь слегка вводят в заблуждение.

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

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

Как следствие, сборщик мусора также не будет заботиться об исключении.

С другой стороны, неуправляемые ресурсы, которые не обрабатываются CG, всегда требуют ручной очистки (через Dispose метод IDisposable интерфейса). Чтобы убедиться, что такие ресурсы возвращаются после возникновения исключения, вам действительно нужно finally предложение. Или, если вы не собираетесь обрабатывать исключение локально, вы можете заменить try … finally на using предложение:

 using (someUnmanagedResource) {
    // … use the resource …
}
// Will implicitly call someUnmanagedResource.Dispose() *whatever happens*!