Перехват ошибок ввода-вывода

[_-Re@l-_]

Вот такой вопрос. Насколько я понял из MSDN, все ошибки ввода-вывода являются производными от IOException. Т.е. вообще все? Ошибка открытия файла, файл в некорректном состоянии, и всё остальное? И правильно ли так будет перехватить все такие ошипки?

try
{
    myFile = new StreamReader(directory);
}
catch(IOException e)
{
   // обработка
}

Или ещё что-то надо учитывать?

[Hollander]

Если быть уверенным, что возможна только ошибка I/O то этот код правильный. Если же в блоке try...catch будет другая логика, то надо обрабатывать и ошибки другого типа. Лично я всегда обрабатываю все ошибки:

try
{
    myFile = new StreamReader(directory);
}
catch(Exception e)
{
   // обработка
}

Но если в случае какого типа ошибки нужна специфическая логика, то так:

try
{
    myFile = new StreamReader(directory);
}
catch(Exception e)
{
if (e is IOException)
   // обработка I/O ошибки
else
  // обработка остальных ошибок
}

[_-Re@l-_]

Опа, прикольно. Спасибо.

[netrino]

Сообщение от Hollander

Но если в случае какого типа ошибки нужна специфическая логика, то так:

try
{
    myFile = new StreamReader(directory);
}
catch(Exception e)
{
if (e is IOException)
   // обработка I/O ошибки
else
  // обработка остальных ошибок
}

Так не надо, для обработки разных типов ошибок есть поддержка со стороны языка в виде множества catch-блоков

try {
  myFile = new StreamReader(directory);
} catch (IOException ioex) {
  ...
} catch (Exception ex) { // или, если информация об исключении не нужна, то просто catch {
  ...
}

[ds.Dante]

Базовый Exception перехватывать не рекомендуется. http://msdn.microsoft.com/ru-ru/library/ms229005.aspx

[Luuzuk]

Не рекомендуется != не нужно. Особенно на верхних уровнях логики. Внезапная смерть программы из-за необработанного некритического исключения тоже не есть хорошо

[ds.Dante]

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

Исключения из правила:
1) Если программа вообще не должна выдавать сообщения об ошибке, например, какой-нибудь скрытый шпион. :)
2) Если каждое исключение должно сопровождаться каким-то действием, при этом исключение не должно подавляться. Например:

try
{
  Foo ();
}
catch (Exception e)
{
  Debug.WriteLine (e);
  throw;
}

3) Вызов стороннего кода, который можно вообще убить, и спокойно продолжить работать в основной программе.

[Luuzuk]

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

Мрут как милые, не проигнорируешь. А назвать "Прекращена работа программы %softname%" осмысленным сообщением у меня бы язык не повернулся.

А во-вторых, непредсказуемое поведение программы из-за какого-нибудь экзотического исключения (которое программист никак не предвидел)

Если обрабатываешь exception, то должен знать как поступить в случае его возникновения. Бездумные конструкции типа

try
{
  //какой-то код
}
catch {  }

я тоже не приветствую.

В случае, если скорректировать работу программы после возникновения ошибки (даже непредусмотренной) не получается, то, безусловно, программа должна завершить работу.
Не тупо свалиться с дефолтным сообщением дотнета, а выдать нормальное сообщение с причиной краха. По хорошему еще и запротоколировать крах в лог.
Хотя в подавляющем большинстве случаев в моих проектах эту логику реализует обработчик Application.UnhandledException (или Dispatcher.UnhandledException)

[Пепел Феникса]

Мрут как милые, не проигнорируешь. А назвать "Прекращена работа программы %softname%" осмысленным сообщением у меня бы язык не повернулся.

у меня лично выдается хорошее сообщение с полной информацией об исключении.

[Luuzuk]

...в дотнете программы не умирают, а...

Не "в дотнете", а в WinForms. Не нужно так обобщать.
В WPF или Silverlight дела обстоят именно так, как я описал.

у меня лично выдается хорошее сообщение с полной информацией об исключении.

В WinForms - да. Давно не использовал эту технологию, забыл как там unhandled exceptions себя ведут
И, тем не менее, остаюсь при мнении, что исключения должен обрабатывать программист. Даже если программа при их возникновении должна завершаться