Что регистрировать при возникновении исключения?

Question

public void EatDinner(string appetizer, string mainCourse, string dessert)
{
   try
   {
      // Code
   }
   catch (Exception ex)
   {
      Logger.Log("Error in EatDinner", ex);
      return;
   }
}

Когда в конкретном методе возникает исключение, что я должен регистрировать?

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

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

Logger.Log("Params: " + appetizer + "," + mainCourse + "," + dessert, ex);

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

Answer 1

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

ИМХО прохождение всего кода для добавления операторов журнала везде может быть излишним - или, по крайней мере, неэффективным в реальном проекте. Вместо этого сосредоточьтесь на наиболее важных частях кода , чтобы максимизировать отдачу от ваших усилий. Эти части кода, как правило, являются местом, где происходит большинство ошибок и / или большинство изменений (будет сделано). Поэтому на практике всякий раз, когда вам нужно прикоснуться к куску кода, подумайте о ведении журнала, проверьте уже присутствующие там операторы журнала (если они есть), проверьте обработку исключений (если есть) - я обычно вижу не только код, подобный вашему примеру, который просто проглатывает перехваченное исключение, но даже пустые или автоматически сгенерированные catch блоки в нашем устаревшем коде ... все это может оставить приложение в неопределенном состоянии, что является ПЛОХОЙ вещью), и подумать, достаточно ли того, что уже есть для вас, чтобы воспроизвести ошибки и понять, что произошло, если произошла ошибка. Затем улучшите его настолько, насколько вам нужно, и можете с разумными усилиями.

Это также помогает обсудить эту тему с вашими товарищами по команде и попытаться выработать примерное соглашение по проекту о том, как регистрировать события, как обрабатывать исключения и т. Д. Это может сэкономить вам много времени, потраченное в противном случае в погоне за ошибками и / или улучшением кода, созданного вашими коллегами: - (

Answer 2

Это довольно ужасный код.Съедает исключение, предположительно оставляя приложение в неопределенном состоянии.В общем, во что бы то ни стало регистрируйте исключение (но не оборачивайте каждый бит кода в блоке try), но затем перебрасывайте его.

Answer 3

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

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

Answer 4

Вот пример от Rico Mariani (CLR perf), почему вы не должны ловить все исключения. Может быть действительно трудно диагностировать реальную проблему.