В C#, как я знаю который исключения поймать?

Запущенные вами методы обычно показывают, какие исключения могут быть созданы. Затем вы можете поймать соответственно.

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

Я рекомендую несколько ссылок:

• Обработка исключений в C #
• Try..Catch
• Исключения и обработка исключений

В документации часто описывается, какие исключения может вызвать метод, и условия, при которых это может произойти. Это особенно верно в отношении справочной документации Microsoft по платформе .NET.

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

За исключением редких ситуаций, я обычно думаю о блоках catch как о запахе кода.

Предотвращайте генерацию исключений, предварительно проверяя условия. Например, при чтении из файла используйте классы в System.IO, чтобы проверить, существует ли файл, вместо использования блока catch для обработки ситуации, когда файл не существует.

Блоки захвата не должны быть частью логики вашего приложения.

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

Исключение (простите): стоит иметь что-то на самом верхнем уровне (например, Application.ThreadException или AppDOmain.UnhandledException), чтобы попытаться зарегистрировать те исключения, которые вы не обработали. Если запись не удалась, вы в любом случае обречены.

Но слепое проглатывание всех исключений (особенно на низком уровне) может привести к очень неприятным сеансам отладки / диагностики.

При использовании методов фреймворка вы можете проверить документацию MSDN. В каждом описании метода есть список потенциально сгенерированных исключений.

В качестве примера посмотрите параграф «Исключения» в документации File.Open () .

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

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

• Если вы абсолютно не можете позволить исключению всплыть и завершить ваше приложение.
• Вызывающий код ожидает, что ваш метод / свойство вызовет исключение, поскольку это атомарная транзакция. В этом случае вы перехватываете все исключения и благополучно возвращаетесь.

Обратной стороной перехвата всех исключений является маскировка потенциально полезного сообщения об ошибке и ее игнорирование, вызывая неожиданные побочные эффекты в вашем приложении.

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

try
{
    // Some Code
}
catch
{
}

Однако, если вам нужно выполнить определенную обработку определенных исключений, вы можете указать несколько блоков catch для одной попытки :

try
{
    // Some Code
}
catch(ArgumentException argE)
{
}
catch(NullReferenceException nullE)
{
}
catch(Exception e)
{
    // Everything else
}

Если вы не можете восстановиться после исключения, не перехватывайте его на этом уровне.

Да, это плохая практика. Эмпирическое правило: «ловите исключения, на которые вы можете отреагировать, и отпускайте другие».

try {
    File.Open(usersChosenFile, FileMode.Open);
} catch(FileNotFoundException) {
    // tell the user the file is gone, give them a chance to respond
    // this is good
} catch(UnauthorizedAccessException) {
    // this is good too
} catch(Exception) {
    // what did you just catch? Who knows. What if its OutOfMemoryException?
    // Do you really want to deal with that here? Let this one go by
}

IMO - не перехватывайте никаких исключений, если вы не планируете повышать их ценность и / или с ними можно справиться только этим методом.

Пожалуйста, имейте общий обработчик исключений, который обрабатывает все необработанные исключения.

HTH.

Как сказал Кайл, делайте ваши методы небольшими по длине, применяйте метод «try / catch» только на небольших участках. Наведите указатель мыши на методы, которые вы вызываете - тогда вы должны получить список исключений. Это не перехватит все перечисленные исключения, но исключения также можно обнаружить эмпирически, если вы напечатаете тип исключения внутри вашего catch (Исключение e) {...} . Вам нужны e.GetType (). FullName и e.StackTrace и e.Message и e.InnerException .. .или часть того, что я перечислил.