Как обработать IOException на FileStream.Close / Dispose

1

На основе документации FileStream.Close/Dispose может генерировать исключение IOException, с другими потоками/службами, которые я отключил от "использования" из-за ситуации исключений при закрытии, оставляя соединение открытым и по существу осиротевшим в пользу следующей модели: это решение поддерживается MSDN Рекомендуемая практика

try 
{
  //do work
  handler.Close(); //or equivalent
}
catch(IOException)
{
  handler.Abort();  
}
finally
{
  handler.Dispose(); 
}

Проблема здесь в том, что в FileStream Close по существу Dispose, и Abort нет. Это в проекте, который не имеет доступа к.net 4.5, поэтому ручное инициирование отмены задачи в ReadAsync недоступно, так что лучшая стратегия для этого, или вы можете объяснить, почему это не является проблемой, в отличие от соединения к SQL/WCF/etc, если это действительно так?

Вариант использования в этом сценарии - загрузка изображения пользователя в элемент управления Silverlight. В настоящее время я использую "использование", поскольку он более краткий/читабельный, чем блок t/c/f, который в этой ситуации не добавляет никакого значения, которое я могу найти.

  • 1
    Где вы видели, что FileStream может генерировать IOException? Насколько мне известно, FileStream.Dispose не будет выбрасывать исключение. Я мог сильно ошибаться в этом, но быстрый просмотр документации не показал, где может возникнуть IOException. Конечно, возможно, что я просто пропустил это. Исходя из того, что я видел, я бы сказал, что завершение FileStream в операторе using - это нормально. Если бы вы могли предоставить ссылку на документацию, в которой говорится, что FileStream.dispose может вызвать исключение IOException, я посмотрю и посмотрим, не можем ли мы предоставить вам более подробные рекомендации.
Теги:
silverlight
filestream
using-statement

1 ответ

2
Лучший ответ

До сегодняшнего дня я не знал, что FileStream.Dispose/Close может генерировать исключение IOException, но, оказывается, это возможно. Не то чтобы я думал, что ОП ошибается.

else {
    // ERROR_INVALID_PARAMETER may be returned for writes
    // where the position is too large (ie, writing at Int64.MaxValue 
    // on Win9x) OR for synchronous writes to a handle opened 
    // asynchronously.
    if (hr == ERROR_INVALID_PARAMETER)
        throw new IOException(Environment.GetResourceString("IO.IO_FileTooLongOrHandleNotSync"));
    __Error.WinIOError(hr, String.Empty);
}

Вышеприведенный код был взят из FileStream.cs, метод - Write.

Есть два случая, когда исключение IOException будет выбрано во время Dispose/Close. В системе Win9x будет использоваться позиция, которая больше, чем Int64.maxValue. Второй пытается написать синхронно с дескриптором, который был открыт асинхронно.

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

Я бы сказал, что в этом случае вы используете "использование". IOException - это край, который вряд ли всплывает, и если это произойдет, вероятно, будет во время разработки.

Если, конечно, вы не работаете на машине с Windows 98, в этом случае вам просто нужно выйти.

Замечание: этот ответ основан на моей интерпретации кода в FileStream.cs. Если бы я сделал какие-либо неправильные предположения, сообщите мне, и я соответствующим образом настрою свой ответ.

  • 0
    Большое спасибо, я не исследовал ситуации, когда исключение может быть выдано очень тщательно, и, честно говоря, я не помню, где я видел возможность исключения, это было на msdn, я думаю, что это, скорее всего, было в описании Файловый поток, где они упоминают также и дескрипторы. Определенно не пишу для Windows 98! :), большое спасибо за объяснение. В конечном счете, это сводится к тому, что я не доверяю компьютеру, поэтому я начинаю паниковать из-за магии высокого уровня, так что спасибо за ослабление моих беспочвенных забот.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню