Здравствуйте, AlexNek, Вы писали:

AN>Чаще всего получается, что есть уже готовый код, в котором понадобилась трассировка. При этом любая новая вставка не должна "модифицировать" существующий код. По крайнем мере, при сравнении должны быть неизменные линии старого кода и новые для трассировки.
Вот это требование не очень понятно, откуда взялось.
При данном способе изменяются не только линии исходного кода но и сам способ вызова.
Способ вызова остаётся тем же. Мы просто окружаем наш код "операторными скобками". То, что стек вызова будет выглядеть по-другому, в большинстве случаев неважно.
Кода, который будет чувствителен к таким нюансам, в природе очень мало.

AN>>>Вот эти должны быть правильнее.
AN>>>http://www.rsdn.ru/forum/dotnet/4641286.1.aspx

Автор: abibok
Дата: 29.02.12

AN>>>http://www.rsdn.ru/forum/dotnet/4641442.1.aspx

Автор: abibok
Дата: 01.03.12

S>>Не знаю, почему вы хотите пояснений мнению, высказанному abibok-ом, от меня.
AN>Вообще это я понял (что авторы разные) только когда искал ссылки, обычно я "вижу" форум в "плоском" виде.
Ну зачем же вы так на него смотрите. Смотрите так, чтобы было понятно, кто кому что отвечает.

AN>А для чего это нужно понимать? Есть код для которого нужно иметь больше информации, гораздо быстрее вставить линию трассировки и глянуть протокол, чем разбираться нужна она или нет.
Давайте разберёмся, какую проблему вы решаете. Если вам хочется по-быстрому воткнуться и посмотреть, то достаточно просто брекпоинта. Если не получается сделать брекпоинт, то можно втыкать какую угодно трассировку — вы же её уберёте из production, так что вопросы качества кода вообще не волнуют.

А если вы заморачиваетесь тем, как же тут правильно делать, то речь о production коде, и вот в нём такие вещи выглядят очень подозрительно.
Потом вычитывать эти тонны мусора, разбираясь, то ли это семь разных проблем, то ли один и тот же exception, залоггированный на семи уровнях — то ещё удовольствие.

S>>Выглядит очень подозрительно. Одно дело, если бы перехват исключения был частью логики. Но тогда бы не было перевыброса.
AN>Для меня выглят абсолютно натурально. Был код без трассировки, в который ее добавили.
А для меня это выглядит как абсолютно бесполезная трассировка. Исключение, если оно было, поймают и уровнями выше. И вся информация про него там будет.
Логично было бы добавить трассировку, скажем, параметров вызова, спровоцировавших исключение — которых в исключении может и не быть.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, AlexNek, Вы писали:

AN>>Чаще всего получается, что есть уже готовый код, в котором понадобилась трассировка. При этом любая новая вставка не должна "модифицировать" существующий код. По крайнем мере, при сравнении должны быть неизменные линии старого кода и новые для трассировки.
S>Вот это требование не очень понятно, откуда взялось.
Откуда взялось сказать также не могу, но всегдв пользуем. По крайней мере, четко видно если что накосячено.
S>При данном способе изменяются не только линии исходного кода но и сам способ вызова.
S>Способ вызова остаётся тем же. Мы просто окружаем наш код "операторными скобками". То, что стек вызова будет выглядеть по-другому, в большинстве случаев неважно.
Если будет в одном конкретном месте, то можно вполне пренебречь, но если будет везде подобный код, то на стек будет просто невозможно смотреть. К тому же данную добавку сделать "на автомате" не так просто. Тут нужно хоть немного "подумать".

if (a())
{
 return b();
}

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

AN>>>>Вот эти должны быть правильнее.
AN>>>>http://www.rsdn.ru/forum/dotnet/4641286.1.aspx

Автор: abibok
Дата: 29.02.12

AN>>>>http://www.rsdn.ru/forum/dotnet/4641442.1.aspx

Автор: abibok
Дата: 01.03.12

S>>>Не знаю, почему вы хотите пояснений мнению, высказанному abibok-ом, от меня.
AN>>Вообще это я понял (что авторы разные) только когда искал ссылки, обычно я "вижу" форум в "плоском" виде.
S>Ну зачем же вы так на него смотрите.
Затем что это практически единственный форум с древовидной структурой для меня. И в Авалоне я видел только ответы.
S>Смотрите так, чтобы было понятно, кто кому что отвечает.
абсолютно неудобно, но это скорее дело привычки.

AN>>А для чего это нужно понимать? Есть код для которого нужно иметь больше информации, гораздо быстрее вставить линию трассировки и глянуть протокол, чем разбираться нужна она или нет.
S>Давайте разберёмся, какую проблему вы решаете. Если вам хочется по-быстрому воткнуться и посмотреть, то достаточно просто брекпоинта. Если не получается сделать брекпоинт, то можно втыкать какую угодно трассировку — вы же её уберёте из production, так что вопросы качества кода вообще не волнуют.

S>А если вы заморачиваетесь тем, как же тут правильно делать, то речь о production коде, и вот в нём такие вещи выглядят очень подозрительно.
S>Потом вычитывать эти тонны мусора, разбираясь, то ли это семь разных проблем, то ли один и тот же exception, залоггированный на семи уровнях — то ещё удовольствие.
Вообще то речь шла только о потери информации о стеке. А с логом разбираться в данном случае довольно просто, смотрим только на первое исключение все что дальше,будет интересовать только для случая отладки "механизма обработки иключений".

S>>>Выглядит очень подозрительно. Одно дело, если бы перехват исключения был частью логики. Но тогда бы не было перевыброса.
AN>>Для меня выглят абсолютно натурально. Был код без трассировки, в который ее добавили.
S>А для меня это выглядит как абсолютно бесполезная трассировка. Исключение, если оно было, поймают и уровнями выше. И вся информация про него там будет.
Кто это сможет гаратировать? Ну и будет как раз не вся информация о стеке.
S>Логично было бы добавить трассировку, скажем, параметров вызова, спровоцировавших исключение — которых в исключении может и не быть.
Кстати, когда игрался с постшарпом так и сделал. Оказалось практически бесполезной вещью. Хотя если лог "прийдет из другого места" будет видимо полезно.

Здравствуйте, AlexNek, Вы писали:
AN>Откуда взялось сказать также не могу, но всегдв пользуем. По крайней мере, четко видно если что накосячено.
Я понял. В целом, мы говорим про два совершенно разных сценария использования трассировки.
Вы говорите про временную трассировку для отладки, когда нужно срочно воткнуть строки в имеющийся код, а потом убрать их.
Я говорю про перманентную трассировку в production code. К примеру, посмотрите, сколько её встроено в System.Net.
Отсюда и разногласия.

случаев неважно.
AN>Если будет в одном конкретном месте, то можно вполне пренебречь, но если будет везде подобный код, то на стек будет просто невозможно смотреть. К тому же данную добавку сделать "на автомате" не так просто. Тут нужно хоть немного "подумать".
Верно, вы правы.

S>>Кода, который будет чувствителен к таким нюансам, в природе очень мало.
AN>Но совсем не хочется узнать, что вдруг нашелся подобный вариант. Да и код для меня становится гораздо хуже читаемым. Логи то видны сразу, а тут в море скобок нужно разбираться.
AN>Затем что это практически единственный форум с древовидной структурой для меня. И в Авалоне я видел только ответы.
S>>Смотрите так, чтобы было понятно, кто кому что отвечает.
AN>абсолютно неудобно, но это скорее дело привычки.

AN>Вообще то речь шла только о потери информации о стеке.
Да не шла об этом речь. Зайдите в веб и включите древовидное представление. Это не sibmama.ru, тут не принято отвечать сразу всем.

AN>Кто это сможет гаратировать? Ну и будет как раз не вся информация о стеке.
Что значит "гарантировать"? Идём в самый-самый верх и смотрим, чем у нас unhandled exception обрабатывается. Откуда будет "не вся" информация — мне непонятно.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, AlexNek, Вы писали:
AN>>Откуда взялось сказать также не могу, но всегдв пользуем. По крайней мере, четко видно если что накосячено.
S>Я понял. В целом, мы говорим про два совершенно разных сценария использования трассировки.
S>Вы говорите про временную трассировку для отладки, когда нужно срочно воткнуть строки в имеющийся код, а потом убрать их.
S>Я говорю про перманентную трассировку в production code. К примеру, посмотрите, сколько её встроено в System.Net.
S>Отсюда и разногласия.
Для нас, трассировка в production code это просто неубранная по разным причинам, трассировка для отладки. Хотя в текущем проекте трассировка есть иключительно только в исходном коде подключаемая через препроцессор.
В любом случае, она пишется так, чтобы ее можно было убрать простым комментарием — и этот принцип еще никогда не нарушался.

S>>>Кода, который будет чувствителен к таким нюансам, в природе очень мало.
AN>>Но совсем не хочется узнать, что вдруг нашелся подобный вариант. Да и код для меня становится гораздо хуже читаемым. Логи то видны сразу, а тут в море скобок нужно разбираться.
AN>>Затем что это практически единственный форум с древовидной структурой для меня. И в Авалоне я видел только ответы.
S>>>Смотрите так, чтобы было понятно, кто кому что отвечает.
AN>>абсолютно неудобно, но это скорее дело привычки.

AN>>Вообще то речь шла только о потери информации о стеке.
S>Да не шла об этом речь. Зайдите в веб и включите древовидное представление. Это не sibmama.ru, тут не принято отвечать сразу всем.
В вебе я практически не работаю с рсдн. А если и попадается, то исключительно для прочтения темы подряд. Ну быстрее же просто колесиком мыши крутить для прокрутки текста.

Да и обычно накладок почти не было.

AN>>Кто это сможет гаратировать? Ну и будет как раз не вся информация о стеке.
S>Что значит "гарантировать"? Идём в самый-самый верх и смотрим, чем у нас unhandled exception обрабатывается.
А кто гарантирует, что данный модуль использует только одна программа? И как по быстрому найти это самый-самый верх? И у меня нет никакой уверенности что исключение туда дойдет, а не пропадет где-то по дороге.
Я бы даже сказал, что пути exception неисповедимы. Вот недавний пример. Обнаружил случайно место, где исключения просто съедались — непорядок, нужно убрать. Хорошо, что сразу протестировал, оказалось, что при этом намертво зависала splash форма. Пришлось записать в баг треккер и откатится назад.
S>Откуда будет "не вся" информация — мне непонятно.
Так именно от этого и пошел весь сыр бор — стек искажается от "внутренних" throw.

S>1. К сожалению, в дотнете нет способа перевыбросить исключение, не исказив его стек. Поэтому вариантов для конкретного фрагмента, в общем-то, нет.

static void Rethrow(Exception ex)
{
    if (ex == null)
    {
        return;
    }

    if (ex.GetType().IsSerializable)
    {
        BinaryFormatter formatter = new BinaryFormatter(null, new StreamingContext(StreamingContextStates.CrossAppDomain));
        MemoryStream stream = new MemoryStream();
        formatter.Serialize(stream, ex);
        stream.Position = 0;

        throw (Exception)formatter.Deserialize(stream);
    }
            
    FieldInfo remoteStackTraceString = typeof(Exception).GetField("_remoteStackTraceString", BindingFlags.Instance | BindingFlags.NonPublic);
    remoteStackTraceString.SetValue(ex, ex.StackTrace + Environment.NewLine);

    throw ex;
}

AN>>Кто это сможет гаратировать? Ну и будет как раз не вся информация о стеке.
S>Что значит "гарантировать"? Идём в самый-самый верх и смотрим, чем у нас unhandled exception обрабатывается. Откуда будет "не вся" информация — мне непонятно.

В том-то и дело, что если на пути от возникновения исключения к самому верхнему catch есть еще хотя бы один try-catch, который ловит и перевыбрасывает используя пустой throw или throw ex, то информация теряется. Такое исключение уже намного сложнее отлаживать.

Более того, сохранять в лог информацию об исключении на самом верху уже поздно, потому что к этому моменту стек раскрутился и все локальные объекты потеряны. Поэтому если мы хотим чего-то больше, чем просто стек вызовов, нужно логировать исключение непосредственно после того, как оно было брошено, но до того, как мы вошли в первый/ближайший catch.

Здравствуйте, AlexNek, Вы писали:
AN>Для нас, трассировка в production code это просто неубранная по разным причинам, трассировка для отладки. Хотя в текущем проекте трассировка есть иключительно только в исходном коде подключаемая через препроцессор.
AN>В любом случае, она пишется так, чтобы ее можно было убрать простым комментарием — и этот принцип еще никогда не нарушался.
Я и говорю — этот сценарий сильно отличается от Production трассировки. В самом фреймворке её полно, и задач убрать её простым комментарием тоже нету.

AN>А кто гарантирует, что данный модуль использует только одна программа? И как по быстрому найти это самый-самый верх? И у меня нет никакой уверенности что исключение туда дойдет, а не пропадет где-то по дороге.
Ещё раз: если вы находитесь в процессе отладки, то у вас только одна программа — та, которую вы отлаживаете, и требований к качеству кода нет. Равно как и нет требования сохранять стек исключения для обработчиков верхнего уровня — вы только что отказались от разбирательств с этими обработчиками.
А если вы хотите вставить трассировку в production-код и отдать библиотеку для повторного использования, то всё будет устроено несколько по-другому

S>>Откуда будет "не вся" информация — мне непонятно.
AN>Так именно от этого и пошел весь сыр бор — стек искажается от "внутренних" throw.
Ещё раз: вы делаете внутренний throw оттого, что боитесь потери информации, и собственно этим её же и обеспечиваете.

Здравствуйте, Sinclair, Вы писали:

S>А если вы хотите вставить трассировку в production-код и отдать библиотеку для повторного использования, то всё будет устроено несколько по-другому
У нас бы не было никакого отличия, более того, вероятно было бы два типа либ — с подключенной трассировкой и вообще без онной. Так как совсем не хочется гонять в длинном цикле даже просто "иф". Хотя может зависеть и от других факторов, но в любом случае трассировка не будет составлять "единное целое" с кодом.

Здравствуйте, AlexNek, Вы писали:

AN>У нас бы не было никакого отличия, более того, вероятно было бы два типа либ — с подключенной трассировкой и вообще без онной. Так как совсем не хочется гонять в длинном цикле даже просто "иф". Хотя может зависеть и от других факторов, но в любом случае трассировка не будет составлять "единное целое" с кодом.
Я понял. Просто это совсем другой подход, чем, скажем, в FCL.