Странная практика обработки исключений

Question

Я видел такой код (на самом деле, когда другой человек набирает его):

catch (Exception ex)
{
    string exception = ex.ToString();
}

Этот код плохой? Если так, то почему? Существует соответствующая «цепочка обработчиков перехвата» (например, более конкретная, приведенная выше, фильтрация до общего перехвата всех исключений, но при преобразовании строки исключения, я думаю, вы преобразуете в строку намного больше, чем, вероятно, необходимо) ( Все, что вам действительно нужно, - это InnerMessage или одно из других свойств строки в зависимости от сценария. Что-то еще не так с этим кодом?

Я также видел, как разработчики ставили точки останова на каждой строке кода. Какой в ​​этом смысл? Почему бы просто не поставить один сверху, а затем использовать «бегать к курсору» (нравится эта функция)?

Наконец, в чем преимущество использования разрыва для всех исключений в Visual Studio?

Answer 1

   string exception = ex.ToString();

Это ничего не делает. Лучше войти в систему или использовать MessageBox.Show (...);.

Точки останова в каждой строке ... не много точек - используйте бег для курсора или шаг за шагом / шаг.

Перерыв на все исключения: я на самом деле использовал. У меня были тихие сбои исключений, которые "обрабатывались" некой библиотекой. Перерыв на все помог мне отследить это. Кроме того, «Break on all» может помочь вам убедиться, что вы получаете только те исключения, которые ожидаете (также помогает не перехватывать универсальный класс «Exception», а только перехватывать конкретное исключение.

Answer 2

Это похоже на ленивого программиста, который:

1. Не хочет правильно обрабатывать исключения
2. Желает место для установки точки останова в случае исключения.

Answer 3

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

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

}

И не переносить предупреждение компилятора о блоке catch, подобном этому ...

catch( Exception ex )
{
  // don't use ex
}

Кроме того, он может не знать о псевдорегире исключений $ .

Answer 4

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

Answer 5

Вчера я только что использовал «разбить на все исключения».

Я преследовал довольно неясную ошибку (на самом деле, код работал отлично, что является самой сложной ошибкой из всех, что можно найти), и пока мой код C # выполнял явно неработающий скрипт IronPython, я продолжал получение ArgumentException сообщений, появляющихся в консоли.

Оказывается, это код IronPython:

try:
    value += x
except ValueError:
    pass

приводит к выдаче и обработке ArgumentException во время выполнения IronPython.

Кроме того, если у вас включена функция «разбить на все исключения», VS фактически разбивает эту строку value += x, вызывает исходный код Python, позволяет проверять локальные значения и т. Д. Довольно приятно. Во всяком случае, теперь, когда я вижу, что эти сообщения об исключениях появляются в консоли, я больше не беспокоюсь, что игнорирую то, что меня укусит.