Что зарегистрироваться, когда исключение происходит?
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);
Существует ли лучший способ зарегистрировать текущую среду? Если я сделаю это этот путь, то я должен буду выписать весь этот материал для каждого метода, который я имею в своем приложении? Там какие-либо лучшие практики касаются сценариев как это?
4 ответа
Как правило, я бы сказал, стремиться регистрировать всю информацию, необходимую для воспроизведения хода событий, ведущих к ошибке . Обратите внимание, что вам не обязательно регистрировать все внутри блока catch : вы можете помещать (отладочные) операторы журнала в свой код, внутри вызываемых методов и т. Д., Которые позволяют вам напрямую следить за происходящим. до исключения. Кроме того, вы должны указать в самом исключении информацию о точном симптоме, который его вызвал.
ИМХО просмотр всего кода для добавления операторов журнала повсюду может быть излишним - или, по крайней мере, не рентабельным в реальном проекте. Вместо этого сосредоточьтесь на наиболее важных частях кода , чтобы максимизировать отдачу от ваших усилий. В этих частях кода обычно происходит наибольшее количество ошибок и / или большинство модификаций (будут) сделаны. Поэтому на практике всякий раз, когда вам нужно прикоснуться к фрагменту кода, подумайте о ведении журнала, проверьте операторы журнала, которые там уже присутствуют (если они есть), проверьте обработку исключений (если таковая есть - я обычно вижу не только код, подобный вашему примеру, который просто проглатывает перехваченное исключение, но даже пустые или автоматически сгенерированные блоки catch в нашем устаревшем коде ... все это может оставить приложение в неопределенном состоянии, что является ПЛОХОЙ ВЕЩЕЙ), и подумайте о том, что является уже этого достаточно, чтобы воспроизвести сбои и понять, что произошло в случае возникновения ошибки. Затем улучшите его настолько, насколько вам нужно, и приложите разумные усилия.
Также полезно обсудить эту тему с товарищами по команде и попытаться разработать примерное соглашение о том, как регистрировать события, как обрабатывать исключения и т. Д. Это может сэкономить вам много времени, которое в противном случае было бы потрачено о поиске ошибок и / или улучшении кода, созданного вашими коллегами: - (
Довольно ужасный код. Он съедает исключение, предположительно оставляя приложение в неопределенном состоянии. В общем, непременно регистрируйте исключение (но не оборачивайте каждый бит кода в блоке try), а затем повторно генерируйте его.
Вот пример от Рико Мариани (CLR perf), почему не следует перехватывать все исключения. Диагностировать настоящую проблему может быть очень сложно.
Ваш фреймворк протоколирования должен захватить как можно больше контекста для вас. По крайней мере, он должен легко фиксировать класс, в котором произошла ошибка. Он также должен регистрировать полное исключение, включая трассировку стека и любые внутренние исключения.
Как я ответил на ваш другой вопрос, вы должны использовать разные уровни журнала. Как только вы это сделаете, если вы используете контейнер с инверсией управления, то довольно просто подключить перехватчик, который будет перехватывать все вызовы методов и, если вы находитесь в режиме отладки, записывать в журнал вызов, временную метку и любые параметры.