Обычно вместо

    using (var stream = new FileStream(path, FileMode.Open))
    using (var reader = new BinaryReader(stream, encoding))
        . . .

пишут

    using (var reader = new BinaryReader(new FileStream(path, FileMode.Open), encoding))
        . . .

расчитывая, что BinaryReader.Close закроет и FileStream.

А что если в конструкторе BinaryReader будет брошено исключение?

Здравствуйте, igna, Вы писали:

BinaryReader/Writer втихую закрывает MemoryStream.

Автор: Odi$$ey
Дата: 23.01.07

Здравствуйте, Odi$$ey, Вы писали:

OE>BinaryReader/Writer втихую закрывает MemoryStream.

Автор: Odi$$ey
Дата: 23.01.07

Спасибо, а что будет, если написать

    using (var reader = new BinaryReader(new FileStream(path, FileMode.Open), encoding))
        . . .

, а конструктор BinaryReader бросит исключение?

Здравствуйте, igna, Вы писали:

I>расчитывая, что BinaryReader.Close закроет и FileStream.
I>А что если в конструкторе BinaryReader будет брошено исключение?

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

З.Ы. Зачем спрашивать, когда прорить куда как быстрее?

Здравствуйте, _FRED_, Вы писали:

_FR>В данном случае это ответственность вызывающего кода. Стрим останется "висеть": что здесь "удивительного" и как, по твоему мнению, могло бы быть иначе?

Аналогичное в C++ это типичная ошибка, но там об этом в книгах пишут (Sutter например), что так программировать неправильно, а в .NET сплошь и рядом примеры пытающиеся закрыть читатель (или писатель) и поток одним using-ом, что в книгах, что в MSDN.

Здравствуйте, igna, Вы писали:

_FR>>В данном случае это ответственность вызывающего кода. Стрим останется "висеть": что здесь "удивительного" и как, по твоему мнению, могло бы быть иначе?

I>Аналогичное в C++ это типичная ошибка, но там об этом в книгах пишут (Sutter например), что так программировать неправильно, а в .NET сплошь и рядом примеры пытающиеся закрыть читатель (или писатель) и поток одним using-ом, что в книгах, что в MSDN.

Что-то не понял Можно пример? Что является типичной ошибкой? "Как" это "неправильно"? Что за "прмиеры"?

Здравствуйте, igna, Вы писали:

I>Здравствуйте, Odi$$ey, Вы писали:

OE>>BinaryReader/Writer втихую закрывает MemoryStream.

Автор: Odi$$ey
Дата: 23.01.07

I>Спасибо, а что будет, если написать

I>

I>    using (var reader = new BinaryReader(new FileStream(path, FileMode.Open), encoding))
I>        . . .
I>

I>, а конструктор BinaryReader бросит исключение?

Вообще, надо сказать, что disposable паттерн тот еще геморрой. Я для себя принял правило, что если объект ко мне пришел откуда-то, то dispose не звать. За вызов dispose должен отвечать код, который объект создал.

Здравствуйте, _FRED_, Вы писали:

_FR>Что-то не понял Можно пример? Что является типичной ошибкой? "Как" это "неправильно"? Что за "прмиеры"?

Не стопроцентный аналог, но тоже про утерянный ресурс:

Herb Sutter, More Exceptional C++, Item 20. An Unmanaged Pointer Problem, Part 1: Parameter Evaluation

А вот и пример из MSDN:

            BinaryReader binReader =
                new BinaryReader(File.Open(fileName, FileMode.Open));
            try
            {
                . . .
            }
            finally
            {
                binReader.Close();
            }

(http://msdn.microsoft.com/en-us/library/system.io.binaryreader.aspx)

Да, у этого конструктора BinaryReader нет параметра encoding, но для конструктора с параметром нет примера, потому первое, что приходит в голову, воспользоваться примером для конструктора без параметра, просто добавив последний:

            BinaryReader binReader =
                new BinaryReader(File.Open(fileName, FileMode.Open), encoding);
            try
            {
                . . .
            }
            finally
            {
                binReader.Close();
            }

А это уже точно (в общем случае) ошибка, поскольку encoding может оказаться равным null, конструктор BinaryReader бросит исключение и FileStream окажется бесхозным. Является ли ошибкой пример приведенный в MSDN, то есть возможно ли и здесь исключение в конструкторе, даже если File.Open вернул успешно сконструированный FileStream, не знаю, но спецификаций исключений в .NET нет, нет потому и никакой гарантии, что в следующей версии этот конструктор BinaryReader не начнет бросать еще какое-нибудь исключение, по этой причине думаю, что лучше самому закрывать FileStream:

            using (var fileStream = File.Open(fileName, FileMode.Open))
            using (var binReader = new BinaryReader(fileStream))
                . . .

Здравствуйте, Константин Л., Вы писали:

КЛ>Вообще, надо сказать, что disposable паттерн тот еще геморрой. Я для себя принял правило, что если объект ко мне пришел откуда-то, то dispose не звать. За вызов dispose должен отвечать код, который объект создал.

А что ты пишешь вместо этого?:

    using (var reader = new BinaryReader(new FileStream(path, FileMode.Open), encoding))
        . . .

Здравствуйте, igna, Вы писали:

I>Аналогичное в C++ это типичная ошибка, но там об этом в книгах пишут (Sutter например), что так программировать неправильно, а в .NET сплошь и рядом примеры пытающиеся закрыть читатель (или писатель) и поток одним using-ом, что в книгах, что в MSDN.

Скорее всего это от того, что в c++ это действительно ошибка, а в .net — так, warning )

Здравствуйте, igna, Вы писали:

I>Здравствуйте, _FRED_, Вы писали:

_FR>>В данном случае это ответственность вызывающего кода. Стрим останется "висеть": что здесь "удивительного" и как, по твоему мнению, могло бы быть иначе?

I>Аналогичное в C++ это типичная ошибка, но там об этом в книгах пишут (Sutter например), что так программировать неправильно, а в .NET сплошь и рядом примеры пытающиеся закрыть читатель (или писатель) и поток одним using-ом, что в книгах, что в MSDN.

Кстати, да. Вот из MSDN:

// Create a file and store the application settings.
public void Close()
{
    using(BinaryWriter binWriter =
        new BinaryWriter(File.Open(fileName, FileMode.Create)))
    {
        binWriter.Write(aspectRatio);
        binWriter.Write(lookupDir);
        binWriter.Write(autoSaveTime);
        binWriter.Write(showStatusBar);
    }
}

При этом в коде конструктора BinaryWriter мы видим, что он элементарно может бросить исключение, если поток не поддерживает запись.

Интересно, почему так

Здравствуйте, MxKazan, Вы писали:

[]

примерам из msdn уже давно нельзя доверять.

Здравствуйте, igna, Вы писали:

I>Здравствуйте, Константин Л., Вы писали:

КЛ>>Вообще, надо сказать, что disposable паттерн тот еще геморрой. Я для себя принял правило, что если объект ко мне пришел откуда-то, то dispose не звать. За вызов dispose должен отвечать код, который объект создал.

I>А что ты пишешь вместо этого?:

I>

I>    using (var reader = new BinaryReader(new FileStream(path, FileMode.Open), encoding))
I>        . . .
I>

2 using'а

Здравствуйте, TK, Вы писали:

TK>Скорее всего это от того, что в c++ это действительно ошибка, а в .net — так, warning )

И что, утечки ресурса не будет?

Здравствуйте, igna, Вы писали:

_FR>>Что-то не понял Можно пример? Что является типичной ошибкой? "Как" это "неправильно"? Что за "прмиеры"?

I>А вот и пример из MSDN:
I>(http://msdn.microsoft.com/en-us/library/system.io.binaryreader.aspx)

Да, пример "не хороший". Написал бы им Content Bug прям в статье в MSDN.

Здравствуйте, igna, Вы писали:

I>И что, утечки ресурса не будет?

Просто закрытие хэндла будет не детерминированое, а когда GC захочется...

Здравствуйте, Константин Л., Вы писали:

КЛ>примерам из msdn уже давно нельзя доверять.

Но с недавних пор появилась возможность сообщить об этом прямо на странице в "не хорошим" примером, чем и нужно пользоваться.

Здравствуйте, chocho, Вы писали:

C>Просто закрытие хэндла будет не детерминированое, а когда GC захочется...

Отчасти это еще хуже чем "детерминированое незакрытие" в C++, поскольку проблема может не выявится во время тестирования.