Использование оператора и try-catch () - наконец повторение?

Вы можете реализовать шаблон самостоятельно, если вам действительно нужно обработать некоторые исключения. Лично я все еще считаю, что проще (и, что более важно, яснее) просто обернуть using в блоке try / catch.

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

Итак, чтобы выполнить прямую адаптацию паттерна, ваш код должен выглядеть примерно так:

{
    FileStream fs;
    try
    {
        fs = File.Open(path);

    }
    catch (FileNotFoundException e) { /* ... */ }
    catch (IOException e) { /* ... */ }
    catch (Exception e) {/* ... */}
    finally
    {
        if (fs != null) fs.Dispose();
    }
}

Лично я бы хотел, чтобы Using был расширен для поддержки блоков Catch и Finally. Поскольку они уже выполняют преобразование кода, не похоже, что это добавит дополнительных сложностей.

Я бы предпочел сохранить оператор using и заключить его в try / catch. Внешний метод try / catch перехватит любые исключения, за которыми вам нужно следить, игнорируя Dispose (). Это дает дополнительное преимущество, так как защищает вас от самого себя, если вы позже проведете рефакторинг, чтобы переместить try / catch в другое место (например, в вызывающую функцию).

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

Самая большая разница между using и try-finally заключается в том, что using вызывает только метод Dispose(). Если вы реализуете свой собственный блок finally, он может выполнять другую логику, например, регистрацию, которая не будет включена в использование.

Если вам нужно явно обработать различные исключительные случаи, которые могут произойти во время выполнения оператора, вы можете заменить using на try/catch/finally и явно вызвать Dispose() в файле finally. Или вы можете поместить try/catch вокруг блока using, чтобы отделить исключительные обстоятельства от обеспечения утилизации.

Единственное, что делает using - это гарантирует, что Dispose () вызывается, даже если внутри блока возникло исключение. Это очень ограниченная, очень специфическая реализация общей структуры try/[catch]/finally.

Важно то, что ни один из этих вариантов не имеет реального влияния - пока он делает то, что вам нужно, читается и понятно, кого это волнует? Не похоже, что дополнительная попытка станет узким местом или чем-то еще!

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

public class Timer : IDisposable
{
    internal Stopwatch _stopwatch;
    public Timer()
    {
        this._stopwatch = new Stopwatch();
        this._stopwatch.Start();
    }

    public void Dispose()
    {
        this._stopwatch.Stop();
    }
}

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

using(Timer timer = new Timer())
{
    //do stuff
}

Конструкция using является сокращением для блока try/finally. То есть компилятор генерирует:

FileStream fs = null;
try
{
    fs = File.Open(path);
    // ...
}
finally
{
    if (fs != null)
        fs.Dispose();
}

Так что правильно использовать using, если вам не нужен catch, но если да, то вам следует просто использовать обычный try/catch/finally.