Как перехваченная исключительная ситуация может быть пустой (не NullReferenceException)?
Ваш текущий шаблон имеет смысл. Следует иметь в виду как Вы использование это управление исходным кодом: что, если необходимо откатывать, или если Вы хотите сделать разность? Блоки, которые Вы описываете, походят точно на правильный дифференциал в тех случаях: разность покажет Вам точно, что изменило в реализации ошибки # (определенный в журнале регистрации), или точно чем новый код был для того, чтобы реализовать опцию. Откат, точно так же только коснется одной вещи за один раз.
3 ответа
Как вы определяете, что e на самом деле равно нулю? Я пробовал несколько примеров и читал спецификацию CLI для исключений, и, похоже, это не допускает нулевого значения исключения. Кроме того, если бы он был нулевым, он не имел бы типа и, следовательно, не смог бы соответствовать критериям фильтра для того, чтобы быть исключительным типом.
Используете ли вы отладчик для проверки этого значения? Если это так, попробуйте переключить его на встроенный assert.
Вы уверены , что вы не попали в линию Exception e?
try
{
//Some Code here
}
catch (Exception e)
{
int i = 0; // breakpoint here
}
Я спрашиваю только потому, что никогда, никогда не видел такого поведения, и я знаю, что если ваша точка останова Exception e, e кажется нулевым. В следующей строке оно не становится нулевым.
Возможно, генерируемое исключение несовместимо с CLS, что на самом деле не должно улавливаться с помощью Try / Catch с фильтром.
Вы должны быть в состоянии поймать только CLS Соответствует try {} catch {} без исключения "аргумент"