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

Question

В моем текущем проекте я вижу много кода такого типа:

public User GetUserByName(string userName) 
{
    try
    {
        // Lots of code here to check if the user is in the cache,
        // get it from the DB if not, set properties on it, etc...
    }
    catch (Exception ex)
    {
        throw new Exception("Exception getting user by name, username: " + userName, ex);
    }
}

Я ценю намерение: наличие локальных переменных действительно полезно для отладки, но использование метода try / catch для каждого кажется слишком большой работой, и это действительно не помогает читабельности. , На данный момент я игнорирую тот факт, что мы генерируем исключение System.Exception, естественно, более конкретный тип был бы лучше, но это не главное в моем вопросе. Также, само собой разумеется, что это копируется и копируется без каких-либо изменений в сообщении об исключении ...

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

Мои первые мысли:

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

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

Любые другие мнения приветствуются!

Answer 1

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

public User GetUserByName(string userName) 
{    
    try    
    {        

    }    
    catch (Exception ex)   
    {        
       logger.Error("Exception GetUserByName. " + ex.Message);
       throw;
    }
}

Answer 2

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

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

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

Answer 3

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

Если вы не добавляете дополнительный контекст в сообщение, значит, вы неправильно используете инструменты ведения журнала. Всегда лучше ловить и перебрасывать, чем вообще не ловить (он выполняет блоки finally), но вы также должны добавлять соответствующие примечания к каждому сообщению регистрации, в противном случае вы фактически повредите свою способность отлаживать код, поскольку не знаю, откуда возникло исключение.

Кроме того, файлы .Log дешевы, нет ничего плохого в том, что в них содержится МНОГО информации, когда вы выдаете ошибку. Чем больше ошибок вы регистрируете, тем легче будет отлаживать производственное приложение.