'использование' оператора по сравнению с 'попыткой наконец'

Рассмотрите возможность, что оба решения плохи, потому что они маскируют исключения .

А try без catch должен, очевидно, быть плохой идеей; см. MSDN для того, почему using оператор аналогично опасен.

Примечание также Microsoft теперь рекомендует ReaderWriterLockSlim вместо ReaderWriterLock.

Наконец, обратите внимание, что примеры Microsoft используют два блока try-catch для предотвращения этих проблем, например,

try
{
    try
    {
         //Reader-writer lock stuff
    }
    finally
    {
         //Release lock
    }
 }
 catch(Exception ex)
 {
    //Do something with exception
 }

А простым, последовательным, чистым решением является хорошая цель, но принятие Вас не может только использовать lock(this){return mydateetc;}, Вы могли бы пересмотреть подход; с большим количеством информации я уверен Stack  Переполнение может помочь;-)

Я лично использую оператор "использования" C# максимально часто, но существует несколько определенных вещей, которые я делаю наряду с ним для предотвращения потенциальных упомянутых проблем. Проиллюстрировать:

void doSomething()
{
    using (CustomResource aResource = new CustomResource())
    {
        using (CustomThingy aThingy = new CustomThingy(aResource))
        {
            doSomething(aThingy);
        }
    }
}

void doSomething(CustomThingy theThingy)
{
    try
    {
        // play with theThingy, which might result in exceptions
    }
    catch (SomeException aException)
    {
        // resolve aException somehow
    }
}

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

В моем Dispose() методы для этих пользовательских IDisposable классы, я ловлю исключения (но НЕ ошибки) и регистрирую их (использующий Log4net). Я никогда не встречался с ситуацией, где любое из тех исключений могло возможно влиять на мою обработку. Потенциальным ошибкам, как обычно, позволяют распространить стек вызовов и обычно оконечную обработку с соответствующим сообщением (ошибка и отслеживание стека) зарегистрированный.

, Если я так или иначе встретился с ситуацией, где значительное исключение могло произойти во время Dispose(), я перепроектирую для той ситуации. Откровенно говоря, я сомневаюсь, что это будет когда-либо происходить.

Между тем, объем и преимущества очистки "использования" делают его одной из моих самых любимых функций C#. Между прочим, я работаю в Java, C# и Python как мои основные языки, с большим количеством других, добавленных тут и там, и "использование" является одной из моих самых любимых функций языка все вокруг, потому что это - практическая, повседневная рабочая лошадь.

Я определенно предпочитаю второй метод. Это более кратко при использовании и менее подвержено ошибкам.

В первом случае кто-то редактирующий код должен бояться вставлять что-либо между Получением (Read|Write) вызов Блокировки и попыткой.

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

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

Для блокировки чтения-записи попытка/выгода могла бы быть самой полезной, но Вы могли также использовать обоих, как так:

using (obj)
{
  try { }
  catch { }
}

так, чтобы можно было неявно назвать интерфейс IDisposable, а также сделать обработку исключений краткой.

Глупый я. Есть способ сделать это еще проще, сделав заблокированные методы частью каждого экземпляра (вместо статических, как в моем предыдущем посте). Сейчас я действительно предпочитаю это, потому что нет необходимости передавать `rwlMyLock_m 'какому-либо другому классу или методу.

class StackOTest
{
    private delegate DateTime ReadLockMethod();
    private delegate void WriteLockMethod();

    static ReaderWriterLock rwlMyLock_m  = new ReaderWriterLock();
    private DateTime dtMyDateTime_m;
    public DateTime MyDateTime
    {
        get
        {
            return ReadLockedMethod(
                delegate () { return dtMyDateTime_m; }
            );
        }
        set
        {
            WriteLockedMethod(
                delegate () { dtMyDateTime_m = value; }
            );
        }
    }

    private DateTime ReadLockedMethod(ReadLockMethod method)
    {
        rwlMyLock_m.AcquireReaderLock(0);
        try
        {
            return method();
        }
        finally
        {
            rwlMyLock_m.ReleaseReaderLock();
        }
    }

    private void WriteLockedMethod(WriteLockMethod method)
    {
        rwlMyLock_m.AcquireWriterLock(0);
        try
        {
            method();
        }
        finally
        {
            rwlMyLock_m.ReleaseWriterLock();
        }
    }
}

SoftwareJedi, у меня нет учетной записи, поэтому я не могу редактировать свои ответы.

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

class StackOTest
{
    static ReaderWriterLock rwlMyLock_m  = new ReaderWriterLock();
    private DateTime dtMyDateTime_m;
    public DateTime MyDateTime
    {
        get
        {
            DateTime retval = default(DateTime);
            ReadLockedMethod(
                delegate () { retval = dtMyDateTime_m; }
            );
            return retval;
        }
        set
        {
            WriteLockedMethod(
                delegate () { dtMyDateTime_m = value; }
            );
        }
    }

    private void ReadLockedMethod(Action method)
    {
        rwlMyLock_m.AcquireReaderLock(0);
        try
        {
            method();
        }
        finally
        {
            rwlMyLock_m.ReleaseReaderLock();
        }
    }

    private void WriteLockedMethod(Action method)
    {
        rwlMyLock_m.AcquireWriterLock(0);
        try
        {
            method();
        }
        finally
        {
            rwlMyLock_m.ReleaseWriterLock();
        }
    }
}

Я удивлен, что никто не предложил инкапсулировать try-finally в анонимные функции. Подобно технике создания экземпляров и удаления классов с помощью оператора using, блокировка сохраняется в одном месте. Я предпочитаю это сам только потому, что я предпочитаю читать слово «наконец», чем слово «удалить», когда я думаю о снятии блокировки.

class StackOTest
{
    private delegate DateTime ReadLockMethod();
    private delegate void WriteLockMethod();

    static ReaderWriterLock rwlMyLock_m  = new ReaderWriterLock();
    private DateTime dtMyDateTime_m;
    public DateTime MyDateTime
    {
        get
        {
            return ReadLockedMethod(
                rwlMyLock_m,
                delegate () { return dtMyDateTime_m; }
            );
        }
        set
        {
            WriteLockedMethod(
                rwlMyLock_m,
                delegate () { dtMyDateTime_m = value; }
            );
        }
    }

    private static DateTime ReadLockedMethod(
        ReaderWriterLock rwl,
        ReadLockMethod method
    )
    {
        rwl.AcquireReaderLock(0);
        try
        {
            return method();
        }
        finally
        {
            rwl.ReleaseReaderLock();
        }
    }

    private static void WriteLockedMethod(
        ReaderWriterLock rwl,
        WriteLockMethod method
    )
    {
        rwl.AcquireWriterLock(0);
        try
        {
            method();
        }
        finally
        {
            rwl.ReleaseWriterLock();
        }
    }
}