Стек: анализируем значения параметров26.12.2017 14:50

Очень часто, глядя на стек падения, хочется увидеть, а с какими значениями параметров были сделаны вызовы. Под отладчиком в VisualStudio мы эти значения посмотреть можем. А как быть в случае, если программа запущена без отладчика и обрабатывает исключения самостоятельно? За ответами добро пожаловать под кат.

Вопрос о значениях параметров для нас не праздный. Чуть ли не первый вопрос, который задают разработчики, когда пробуют наш крэш-репортер: «А значения параметров посмотреть можно?»

Что-ж, поисследуем проблему поподробнее.

Вне зависимости от того, обработанное у нас исключение, или нет, изначально мы имеем сам объект Exception (и цепочку его InnerException-ов).

Стек падения добывается из свойства Exception.StackTrace, или можно его получить чуть в более подробном виде, создав объект типа System.Diagnostics.StackTrace. И если по фреймам, содержащимся в StackTrace, можно определить, какие методы вызывались, и какие у них сигнатуры, то значения параметров и ссылки на объекты (this) определить не получается.

Что же делать? Раз рантайм из коробки не отдаёт нужную нам информацию, попробуем собрать её самостоятельно.

Возьмём простейший код:

public void DoWork(string work) {
    DoInnerWork(work, 5);
}
public void DoInnerWork(string work, int times) {
    object o = null;
    o.ToString();
}

Завернём в содержимое методов try/catch. Каждое пойманное исключение зарегистрируем вместе со значениями параметров метода и отправим дальше:

public void DoWork(string work) {
    try {
        DoInnerWork(work, 5);
    }
    catch (Exception ex) {
        LogifyAlert.Instance.TrackArguments(ex, work);
        throw;
    }
}

public void DoInnerWork(string innerWork, this, int times) {
    try {
        object o = null;
        o.ToString();
    }
    catch (Exception ex) {
        LogifyAlert.Instance.TrackArguments(ex, this, innerWork, times);
        throw;
    }
}

Метод Track будет иметь сигнатуру

public void TrackArguments(Exception ex, object instance, params object[] args)

и будет складывать себе во внутренний список или в словарь значения аргументов таким образом, чтобы их можно было привязать к соответствующим строчкам из Exception.StackTrace. Также важно в правильные моменты очищать полученный список, в противном случае его содержимое станет неактуально уже для второго брошенного исключения. Какие это моменты? Вход в метод и успешный (без выброса исключения) выход из него, а также вход в глобальный обработчик исключений. Примерно вот так:

public void DoWork(string work) {
    LogifyAlert.Instance.ResetTrackArguments();
    try {
        DoInnerWork(work, 5);
        LogifyAlert.Instance.ResetTrackArguments();
    }
    catch (Exception ex) {
        LogifyAlert.Instance.TrackArguments(ex, work);
        throw;
    }
}
public void DoInnerWork(string innerWork, this, int times) {
    LogifyAlert.Instance.ResetTrackArguments();
    try {
        object o = null;
        o.ToString();
        LogifyAlert.Instance.ResetTrackArguments();
    }
    catch (Exception ex) {
        LogifyAlert.Instance.TrackArguments(ex, this, innerWork, times);
        throw;
    }
}

void MethodWithHandledException(string work) {
    LogifyAlert.Instance.ResetTrackArguments();
    try {
        DoInnerWork(work, 5);
        LogifyAlert.Instance.ResetTrackArguments();
    }
    catch (Exception ex) {
        HandleException(ex);
        LogifyAlert.Instance.ResetTrackArguments();
    }
}
void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e) {
    var map = LogifyAlert.Instance.MethodArgumentsMap;
    ExceptionTracker.Reset();
    // handle exception below
}

Выглядит феерично, код окончательно превратился в нечитаемое говно нечто. Первая реакция — снести и забыть, как страшный сон. Останавливает лишь то, что как ни крути, принцип неизменен, и значения параметров всё равно придётся собрать своими руками (осторожно, 18+, много мата). Вопросы красоты кода обязательно будем решать, но только после того, как добьёмся работоспособности системы.

Как привязать значения параметров к строчкам стека? По порядковому номеру фрейма в стеке, вестимо! В тот момент, когда мы создаём System.Diagnostics.StackTrace, текущий фрейм всегда имеет индекс 0, а количество фреймов может быть разным. Когда исключение кидается впервые, кол-во фреймов (глубина стека) максимальна, во всех последующих rethrow этого же исключения глубина стека будет только меньше. Таким образом, номер строки в стеке (для конкретного исключения) есть разница между максимальной и текущей глубиной стека. В виде кода:

public void TrackArguments(Exception ex, MethodCallInfo call) {
    StackTrace trace = new StackTrace(0, false);
    int frameCount = trace.FrameCount;
    MethodCallStackArgumentMap map;
    if (!MethodArgumentsMap.TryGetValue(ex, out map)) {
        map = new MethodCallStackArgumentMap();
        map.FirstChanceFrameCount = frameCount;
        MethodArgumentsMap[ex] = map;
    }
    int lineIndex = map.FirstChanceFrameCount - frameCount;
    map[lineIndex] = call;
}

Где MethodCallInfo выглядит следующим образом:

public class MethodCallInfo {
    public object Instance { get; set; }
    public MethodBase Method { get; set; }
    public IList