Как бороться с исключениями

Question

Мой технический руководитель настаивает на этом механизме исключений:

try
{
    DoSth();
}
catch (OurException)
{
    throw;
}
catch (Exception ex)
{
    Util.Log(ex.Message, "1242"); // 1242 is unique to this catch block
    throw new OurException(ex);
}

1242 - это идентификатор метода catch, который обрабатывает исключение, отличное от OurException. Каждый блок catch в проекте должен иметь уникальный идентификатор, чтобы мы могли знать, где произошло исключение, просматривая журналы.

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

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

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

Edit2: Спасибо всем. Я использовал ваши ответы как часть моего аргумента против этого, но мне сказали, что вы недостаточно опытны и не знаете, как справляться с реальными жизненными ситуациями. Я должен идти этим путем.

Answer 1

Мне кажется, что трассировка стека - лучший способ справиться с этим. Что произойдет, если вы по ошибке повторно используете номер?

Что касается того, является ли это хорошей идеей или нет, в отсутствие какой-либо дополнительной информации я склонен сказать "нет". Если каждый вызов метода заключен в блок try / catch, это будет очень дорого. Как правило, исключения относятся к двум лагерям - тем, на которые можно разумно рассчитывать и с которыми можно иметь дело, и тем, которые действительно являются ошибками (или, по крайней мере, не ожидаемыми). Мне кажется, что использование метода дробовика для обнаружения всех исключений может сделать больше, чтобы скрыть последние, чем помочь в их разрешении. Это было бы особенно верно, если бы на верхнем уровне вы перехватили все исключения, поэтому единственной записью, которая у вас есть, является сообщение журнала.

Answer 2

Регистрация трассировки стека будет намного лучше, чем жестко закодированное число. Число ничего не говорит вам о том, что рутина называется это.

Кроме того, с этим номером сложно работать, и при этом он подвержен ошибкам.

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

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

Answer 3

Все выглядит правильно, кроме этого странного числа.

Трассировка стека будет содержать необходимую информацию.

Answer 4

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