Случаи, когда оператор использования и IDisposable никогда не должны использоваться

Я думаю, что более серьезная проблема - это выброс исключений в Dispose . Шаблоны RAII обычно прямо заявляют, что этого делать не следует, поскольку это может создать ситуации, подобные этой. Я имею в виду, каков путь восстановления для чего-то, что не удаляется правильно, кроме простого завершения выполнения?

Кроме того, похоже, что этого можно избежать с помощью двух операторов try-catch:

try
{
    using(...)
    {
        try
        {
            // Do stuff
        }
        catch(NonDisposeException e)
        {
        }
    }
}
catch(DisposeException e)
{
}

Единственная проблема, которая может здесь возникнуть, это если DisposeException совпадает с NonDisposeException или является его супертипом, и вы пытаетесь повторно выбросить из ловушки NonDisposeException . В этом случае блок DisposeException перехватит его. Таким образом, вам может потребоваться дополнительный логический маркер, чтобы проверить это.

Единственный известный мне случай - это клиенты WCF. Это связано с ошибкой конструкции в WCF - Dispose не должен никогда генерировать исключения. Они пропустили это.

Одним из примеров является свойство IAsyncResult.AsyncWaitHandle . Проницательный программист поймет, что классы WaitHandle реализуют IDisposable и, естественно, попытаются с жадностью избавиться от них. За исключением того, что большинство реализаций APM в BCL фактически выполняют отложенную инициализацию WaitHandle внутри свойства. Очевидно, в результате программист проделал больше работы, чем было необходимо.

Так где же поломка? Что ж, Microsoft испортила интерфейс IAsyncResult . Если бы они следовали своему собственному совету, IAsyncResult был бы производным от IDisposable , поскольку подразумевается, что он содержит одноразовые ресурсы. Проницательный программист тогда просто вызовет Dispose для IAsyncResult и позволит ему решить, как лучше всего расположить его составляющие.

Это один из классических второстепенных случаев, когда избавление от IDisposable может быть проблематичным. Джеффри Рихтер фактически использует этот пример, чтобы аргументировать (ошибочно, на мой взгляд), что вызов Dispose не является обязательным. Вы можете прочитать дебаты здесь .

Общее практическое правило простое: когда класс реализует IDisposable, используйте , используя . Когда вам нужно отловить ошибки, используйте try / catch / finally , чтобы иметь возможность отловить ошибки.

Однако есть несколько замечаний.

1. Вы спрашиваете, существуют ли ситуации, когда IDisposable не следует использовать. Что ж: в большинстве случаев вам не нужно его реализовывать. Используйте его, когда вы хотите своевременно освободить ресурсы, а не ждать, пока сработает финализатор.

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

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

4. Использование с использованием - это одно, но не путайте его с использованием , попробуйте / finally . Оба они равны, но оператор using упрощает жизнь, добавляя проверку области видимости и проверку на null, что каждый раз сложно делать вручную.Оператор using переводится в это (из стандарта C #):

    {
   SomeType withDispose = новый SomeType ();
   пытаться
    {
    // использовать withDispose
    }
   наконец-то
    {
   если (withDispose! = ноль)
    {
    ((IDisposable) withDispose) .Dispose ();
    }
    }
   }
   

5. Бывают случаи, когда обертывание объекта в использующий блок не требуется. Такие случаи редки. Они случаются, когда вы обнаруживаете, что наследуете интерфейс, унаследованный от IDisposable , на всякий случай дочерний элемент потребует удаления. Часто используемый пример - IComponent, который используется с каждым элементом управления (Form, EditBox, UserControl, вы называете его). И я редко вижу, чтобы люди заключали все эти элементы управления в using-выражения. Другой известный пример - IEnumerator . При использовании его потомков также редко можно встретить блоки using.

Заключение

Используйте оператор using повсеместно и рассудительно относитесь к альтернативам или опускайте их. Убедитесь, что вы знаете о последствиях (не) его использования, а также о равенстве с использованием и try / finally. Нужно что-нибудь поймать? Используйте try / catch / finally.