Является ли злоупотреблением использование IDisposable и использование в качестве средства для получения ограниченного поведения для безопасности исключений?

Если вам просто нужен чистый код с ограниченной областью видимости, вы также можете использовать лямбды, á la

myFribble.SafeExecute(() =>
    {
        myFribble.DangerDanger();
        myFribble.LiveOnTheEdge();
    });

где метод .SafeExecute(Action fribbleAction) оборачивает блок try - catch - finally.

Эрик Ганнерсон, работавший в группе разработчиков языка C #, дал этот ответ почти на тот же вопрос:

Дуг спрашивает:

re: Оператор блокировки с тайм-аутом ...

Я проделывал этот трюк раньше, чтобы иметь дело с общими шаблонами в различных методах. Обычно получение блокировки, но есть и другие. Проблема в том, что это всегда похоже на взлом, поскольку объект на самом деле не одноразовый, а скорее «call-back-at-the-end-of-a-scope -able».

Дуг,

Когда мы решили [sic] использовать оператор, мы решили назвать его «использование», а не что-то более конкретное для удаления объектов, чтобы его можно было использовать именно для этого сценария.

Это скользкий спуск. IDisposable имеет контракт, поддерживаемый финализатором. Финализатор в вашем случае бесполезен. Вы не можете заставить клиента использовать оператор using, только поощряйте его это делать. Вы можете заставить его использовать такой метод:

void UseMeUnlocked(Action callback) {
  Unlock();
  try {
    callback();
  }
  finally {
    Lock();
  }
}

Но без ламдов это становится немного неловко. Тем не менее, я использовал IDisposable, как и вы.

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

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

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

Примером из реальной жизни является BeginForm ASP.net MVC. В основном вы можете написать:

Html.BeginForm(...);
Html.TextBox(...);
Html.EndForm();

or

using(Html.BeginForm(...)){
    Html.TextBox(...);
}

Html.EndForm вызывает Dispose, а Dispose просто выводит тег </form>. Хорошая вещь в этом заключается в том, что скобки {} создают видимую «область видимости», которая упрощает просмотр того, что находится внутри формы, а что нет.

Я бы не стал злоупотреблять им, но, по сути, IDisposable - это просто способ сказать: «Вы ДОЛЖНЫ вызвать эту функцию, когда закончите с ней». MvcForm использует его, чтобы убедиться, что форма закрыта, Stream использует его, чтобы убедиться, что поток закрыт, вы можете использовать его, чтобы убедиться, что объект разблокирован.

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

• Dispose должен быть функцией, которая должна выполняться всегда, поэтому не должно быть никаких условий, кроме Null-Checks.
• После Dispose () объект нельзя использовать повторно. Если мне нужен объект многократного использования, я бы предпочел дать ему методы открытия / закрытия, а не уничтожать. Поэтому я бросаю InvalidOperationException при попытке использовать удаленный объект.

В конце концов, все дело в ожиданиях. Если объект реализует IDisposable, я предполагаю, что ему нужно выполнить некоторую очистку, поэтому я называю это. Я думаю, что это обычно лучше, чем наличие функции «Завершение работы».

При этом мне не нравится эта строка:

this.Frobble.Fiddle();

Поскольку FrobbleJanitor теперь «владеет» Frobble, я задаюсь вопросом, не лучше ли было бы вместо этого вызвать Fiddle на Frobble в Janitor?

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

Подключаюсь к этому: я согласен с большинством присутствующих в том, что это хрупко, но полезно. Я хотел бы указать вам на System.Transaction.TransactionScope, который делает то, что хотите сделать вы.

Вообще мне нравится синтаксис, он убирает много лишнего из реального мяса. Пожалуйста, подумайте о том, чтобы дать вспомогательному классу хорошее имя - возможно ... Scope, как в примере выше. Название должно указывать на то, что оно инкапсулирует фрагмент кода. * Scope, * Block или что-то подобное должно это делать.

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

Что говорит спецификация языка C #?

Цитата из спецификации языка C #:

8.13 Оператор using

[...]

Ресурс - это класс или структура, реализующая System.IDisposable, которая включает единственный метод без параметров с именем Dispose. Код, использующий ресурс, может вызвать Dispose, чтобы указать, что ресурс больше не нужен. Если Dispose не вызывается, автоматическое удаление в конечном итоге происходит как следствие сборки мусора.

Код, использующий ресурс - это, конечно, код, начинающийся с ключевого слова using и идущий до области, прикрепленной к using.

Думаю, это нормально, потому что Lock - это ресурс.

Возможно, ключевое слово using было выбрано неправильно. Возможно, его следовало назвать scoped.

Тогда мы можем рассматривать почти все как ресурс. Дескриптор файла. Сетевое подключение ... Нить?

Нить???

Используете (или злоупотребляете) ключевым словом using?

Было бы блестящим, если бы (ab) использовал ключевое слово using, чтобы убедиться, что работа потока завершена перед выходом из области видимости?

Херб Саттер, кажется, думает, что это блестяще, поскольку он предлагает интересное использование шаблона IDispose для ожидания завершения работы потока:

http://www.drdobbs.com/go-parallel/article/showArticle.jhtml?articleID=225700095.

Вот код, скопированный из статьи:

// C# example
using( Active a = new Active() ) {    // creates private thread
       …
       a.SomeWork();                  // enqueues work
       …
       a.MoreWork();                   // enqueues work
       …
} // waits for work to complete and joins with private thread

Хотя код C # для активного объекта не предоставляется, написано, что C # использует шаблон IDispose для кода, версия C ++ которого содержится в деструкторе. И, глядя на версию C ++, мы видим деструктор, который ожидает завершения внутреннего потока перед завершением, как показано в этом другом отрывке из статьи:

~Active() {
    // etc.
    thd->join();
 }

Так что, что касается Херба, он блестящий.

Я считаю, что ответ на ваш вопрос отрицательный, это не будет злоупотреблением IDisposable.

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

Поскольку вы создаете new FrobbleJanitor явно каждый раз, когда переходите к оператору using, вы никогда не используете один и тот же объект FrobbeJanitor дважды. И поскольку его цель - управлять другим объектом, Dispose кажется подходящим для задачи по освобождению этого («управляемого») ресурса.

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

Единственное, о чем я лично беспокоюсь, это то, что менее ясно, что происходит с using (var janitor = new FrobbleJanitor()), чем с более явным блоком try..finally, где операции Lock & Unlock видны напрямую. Но выбор подхода, вероятно, зависит от личных предпочтений.

Я думаю, ты все сделал правильно. Перегрузка Dispose () была бы проблемой, когда тот же класс позже провел очистку, которую он действительно должен был выполнить, и время жизни этой очистки изменилось, чтобы отличаться от времени, когда вы ожидаете удерживать блокировку. Но поскольку вы создали отдельный класс (FrobbleJanitor), который отвечает только за блокировку и разблокировку Frobble, вещи достаточно разделены, вы не столкнетесь с этой проблемой.

Я бы переименовал FrobbleJanitor, вероятно, во что-то вроде FrobbleLockSession.

Это не оскорбление. Вы используете их для того, для чего они созданы. Но вам, возможно, придется рассматривать друг друга в соответствии с вашими потребностями. Например, если вы выбираете «артистизм», вы можете использовать «using», но если ваш фрагмент кода выполняется много раз, то по соображениям производительности вы можете использовать «попробовать» .. «наконец» конструкции, потому что «использование» обычно включает создание объекта.