Всегда ли Stream.Dispose вызывает Stream.Close (и Stream.Flush)

Могу ли я просто вызвать MySW.Dispose () и пропустить закрытие, даже если оно предусмотрено?

Да, вот для чего.

Существуют ли какие-либо реализации Stream, которые не работают должным образом (например, CryptoStream)?

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

Если этого не произойдет, то это будет ошибкой.

Если нет, то это просто плохой код:

Нет, этот код является рекомендуемым способом работы с объектами, реализующими IDisposable.

Более полезная информация содержится в принятом ответе на вопрос Close and Dispose - что вызывать?

Я использовал Reflector и обнаружил, что System.IO.Stream.Dispose выглядит так:

public void Dispose()
{
    this.Close();
}

Как сказал Дэниел Брукнер, Dispose и Close - это одно и то же.

Однако Stream НЕ вызывает Flush (), когда он удаляется / закрывается. FileStream (и я предполагаю, что любой другой Stream с механизмом кеширования) действительно вызывает Flush () при удалении.

Если вы расширяете Stream, MemoryStream и т. Д., Вам нужно будет реализовать вызов Flush () при удалении / закрытии, если это необходимо.

Все стандартные потоки (FileStream, CryptoStream) будут пытаться очистить при закрытии / удалении. Я думаю, что вы можете положиться на это для любых реализаций потоков Microsoft.

В результате Close / Dispose может вызвать исключение в случае сбоя сброса.

Фактически в IIRC была ошибка в реализации FileStream .NET 1.0, заключающаяся в том, что она не могла освободить дескриптор файла, если сброс выдает исключение. Это было исправлено в .NET 1.1 путем добавления блока try / finally к методу Dispose (boolean).

И StreamWriter.Dispose (), и Stream.Dispose () освобождают все ресурсы, удерживаемые объектами. Оба они закрывают основной поток.

Исходный код Stream.Dispose () (обратите внимание, что это детали реализации, поэтому не полагайтесь на это):

public void Dispose()
{
    this.Close();
}

StreamWriter.Dispose () (то же, что и Stream.Dispose ()):

protected override void Dispose(bool disposing)
{
    try
    {
        // Not relevant things
    }
    finally
    {
        if (this.Closable && (this.stream != null))
        {
            try
            {
                if (disposing)
                {
                    this.stream.Close();
                }
            }
            finally
            {
                // Not relevant things
            }
        }
    }
}

Тем не менее, я обычно неявно закрываю потоки / потоковые записи перед их удалением - я думаю, что это выглядит чище.

Для объектов, которые необходимо закрыть вручную, следует приложить все усилия для создания объекта в блоке using.

//Cannot access 'stream'
using (FileStream stream = File.Open ("c:\\test.bin"))
{
   //Do work on 'stream'
} // 'stream' is closed and disposed of even if there is an exception escaping this block
// Cannot access 'stream' 

Таким образом, невозможно получить неправильный доступ к «потоку» вне контекста предложения using, и файл всегда будет закрыт.

Я просмотрел источник .net для класса Stream, у него было следующее, что предполагает, что да, вы можете ...

    // Stream used to require that all cleanup logic went into Close(),
    // which was thought up before we invented IDisposable.  However, we 
    // need to follow the IDisposable pattern so that users can write
    // sensible subclasses without needing to inspect all their base
    // classes, and without worrying about version brittleness, from a
    // base class switching to the Dispose pattern.  We're moving 
    // Stream to the Dispose(bool) pattern - that's where all subclasses
    // should put their cleanup starting in V2. 
    public virtual void Close() 
    {
        Dispose(true); 
        GC.SuppressFinalize(this);
    }

    public void Dispose() 
    {
        Close(); 
    } 

Stream.Close реализуется вызовом Stream.Dispose или наоборот, поэтому методы эквивалентны. Stream.Close существует только потому, что закрытие потока звучит более естественно, чем удаление потока.

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