Подтвердить что ты не робот

Является ли пустой try/catch равным catching Exception?

try {
}
catch (Exception) {
}

могу ли я просто написать

try {
}
catch {
}

Это нормально в С#.NET 3.5. Код выглядит лучше, но я не знаю, является ли то же самое.

4b9b3361

Ответ 1

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

try {
}
catch (Exception ex) {
  // Log exception message here...
}

Кроме того, как правило, плохой способ поймать общий Exception класс, если вы можете вместо этого перехватить определенные исключения (например, исключение IOException), используя первую форму.

Ответ 2

Они не одинаковые.

catch (исключение) {} будет отслеживать только управляемые исключения; catch {} также будет использовать исключения, отличные от CLS: http://msdn.microsoft.com/en-gb/bb264489.aspx

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

Изменить. Оказывает, что .NET 2.0+ обертывает значения, поэтому они одинаковы. Это немного облегчение!

Ответ 3

Изменить: с С# 2.0 исключения, не совместимые с CLS, могут быть обнаружены в обоих направлениях.

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

В CLR 2.0 MS представила RuntimeWrappedException, который является типом исключения, совместимым с CLS, для инкапсуляции исключений, не совместимых с CLS, Компилятор С# по-прежнему не позволяет вам их бросать, но он может поймать их с синтаксисом catch (Exception) {}.

Вот почему компилятор С# выдаст предупреждение CS1058, если вы одновременно используете оба предложения в CLR 2.0 или новее.

Таким образом, они фактически идентичны.

Ответ 4

То же самое, но если вы положите e после Exception в свой первый пример, тогда вы знаете, какое исключение было выбрано...

edit: вы никогда не должны ломать исключение, как вы знаете, как правильно его обрабатывать?

Ответ 5

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

try {
}
catch (Exception e) {
//do something with e
}

Ответ 6

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

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

try
{
    // Some code here
}
catch(Exception ex)
{
    // Do some logging
    throw;
}

ИЛИ

try
{
    // Some code here
}
catch(Exception ex)
{
    // Do some logging
    // wrap your exception in some custom exception
    throw new CustomException("Some custom error message, ex); 
}

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

Ответ 7

Они различны, как указано:

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

Вы можете увидеть разницу в генерации IL:

//no (Exception)
.try L_0001 to L_0005 catch object handler L_0005 to L_000a

//with (Exception)
.try L_0001 to L_0005 catch [mscorlib]System.Exception handler L_0005 to L_000a

Ответ 8

Конструктор параметров less приведет к обработке типов исключений, исходящих из некоторых других языков, исключение, которые не унаследованы от класса С# SYSTEM.EXCEPTION.