a>> Не делайте так. Происходит потеря информации о месте возникновения исходного исключения.
AN>А можно пояснить, что то мысль про место не совсем понятна. И как нужно правильно?

It is very important to collect as much information about failure as it is possible. It is not enough to know that something wrong has happened. We need to know how it happened, what was done before the failure, and what the state of the system was. In other words, we need history.

One of the most valuable parts of the history is call stack. Misuse of try-catch construction in our code may lead to call stack cut or even loss. Here I will try to demonstrate several examples of such misuse.

Example 1:

try
{
    // some logic here
}
catch
{
    // Simply re-throwing all exceptions
    // in order to show that the base class catches the exceptions and
    // fails appropriately.
    throw;
}

What’s wrong? Consider the following program.

 1: class Program
 2: {
 3:    static void f(bool b)
 4:    {
 5:        if (b)
 6:            throw new ApplicationException();
 7:    }
 8:
 9:    static void RunTest()
10:    {
11:        try
12:        {
13:            f(false);
14:            f(true);
15:            f(false);
16:        }
17:        catch
18:        {
19:            throw;
20:        }
21:    }
22:    
23:    static void Main(string[] args)
24:    {
25:        try
26:        {
27:            RunTest();
28:        }
29:        catch (Exception e)
30:        {
31:            string s = e.ToString();
32:        }
33:    }
34: }

After run s =
System.ApplicationException: Error in the application.
at Program.f(Boolean b) in c:\test\Program.cs:line 6
at Program.RunTest() in c:\test\Program.cs:line 19
at Program.Main(String[] args) in c:\test\Program.cs:line 27

What was the reason for exception? That information was lost. We don’t know what part of the code caused the error – the first f-function, the second or the third.

Here we can have 3 different errors with the same stack. To get the root of the problem we need to do manual investigation, what is difficult and is not always possible.

Example 2:

try
{
    // some logic here
}
catch (Exception e)
{
    throw e;
}

Pretty similar to example 1, note that we use “throw e” instead “throw” here. Look how it works:

 1: class Program
 2: {
 3:    static void f(bool b)
 4:    {
 5:        if (b)
 6:            throw new ApplicationException();
 7:    }
 8:
 9:    static void RunTest()
10:    {
11:        try
12:        {
13:            f(false);
14:            f(true);
15:            f(false);
16:        }
17:        catch
18:        {
19:            throw e;
20:        }
21:    }
22:    
23:    static void Main(string[] args)
24:    {
25:        try
26:        {
27:            RunTest();
28:        }
29:        catch (Exception e)
30:        {
31:            string s = e.ToString();
32:        }
33:    }
34: }

After run s =
System.ApplicationException: Error in the application.
at Program.RunTest() in c:\test\Program.cs:line 19
at Program.Main(String[] args) in c:\test\Program.cs:line 27

Here even more information was lost. We only know that something has happened somewhere in try-catch block. Manual investigation is required.

Summary:

Do not use try-catch where it is not necessary. If you are not sure about that then it is not necessary, let the base class do its work.
At catch be as specific as possible, catch only expected exceptions, do not catch all exceptions (System.Exception) unless it is required by code logic.
If you really need to throw your own exception in a catch block, the best way to do this is to throw a new exception and include the old one as the inner exception:

try
{
    // some logic here
}
catch (SomeException e)
{
    // log some more info here
    throw new SomeException("descriptive message", e);
}

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

И что вы предлагаете-то? Не пользоваться throw?

A>И что вы предлагаете-то? Не пользоваться throw?

Вы читали то, что я написал? Какой смысл пытаться что-то объяснить, придумывать красивые примеры, рассказывать о своем опыте наступания на грабли, если все это перечеркивается вот таким "И чо?"

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

A>>И что вы предлагаете-то? Не пользоваться throw?
A>Вы читали то, что я написал? Какой смысл пытаться что-то объяснить, придумывать красивые примеры, рассказывать о своем опыте наступания на грабли, если все это перечеркивается вот таким "И чо?"

Из вашего примера следует (впрочем это давно известная истина), что throw; лучше чем throw e;, потому что не происходит потеря информации.
В сообщении на которое вы отвечали и так написано throw; и вы написали так не делать, потому что происходит потеря информации.
Итого, вы написали два сообщения противоречащих друг другу.

A>Из вашего примера следует (впрочем это давно известная истина), что throw; лучше чем throw e;, потому что не происходит потеря информации.

Я все же настоятельно советую прочитать мой пример до конца, а не пытаться угадывать.

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

a> a>> Не делайте так. Происходит потеря информации о месте возникновения исходного исключения.

a> AN>А можно пояснить, что то мысль про место не совсем понятна. И как нужно правильно?

По моему, слишком академично.

a> It is very important to collect as much information about failure as it is possible.
Ну да еще и фото пользователя присобачить.
It is not enough to know that something wrong has happened. We need to know how it happened, what was done before the failure, and what the state of the system was. In other words, we need history.
Да это все хотят, но непонятно как получить. История обычно следующая — нажимали кнопочки она и вылетела.

a> One of the most valuable parts of the history is call stack.
Можно было голосование устроить как часто его получают и насколько он практически полезен. И самое интересное сколько % будет иметь номер строки и кто будет ее искать в данном релизе.
Misuse of try-catch construction in our code may lead to call stack cut or even loss. Here I will try to demonstrate several examples of such misuse.

a> Example 1:

a>

a> try
a> {
a>     // some logic here
a> }
a> catch
a> {
Кстати, именно здесь и был лог, насколько я помню, в предыдущем примере
a>     // Simply re-throwing all exceptions
a>     // in order to show that the base class catches the exceptions and
a>     // fails appropriately.
a>     throw;
a> }
a>

Что то об этой конструкции забыто

try
{
 ...
}
catch
{
  // по барабану
}

a> What’s wrong? Consider the following program.

a>

a>  1: class Program
a>  2: {
a>  3:    static void f(bool b)
a>  4:    {
a>  5:        if (b)
a>  6:            throw new ApplicationException();
Давайте всегда и везде кидать просто ApplicationException :)
a>  7:    }
...
a>

a> After run s =
a> System.ApplicationException: Error in the application.
a> at Program.f(Boolean b) in c:\test\Program.cs:line 6
a> at Program.RunTest() in c:\test\Program.cs:line 19
a> at Program.Main(String[] args) in c:\test\Program.cs:line 27

a> What was the reason for exception? That information was lost.
Она теряется автоматом как только программа уходит наружу.
We don’t know what part of the code caused the error – the first f-function, the second or the third.
Почти ненужная инфа в реале. Гораздо важнее знать больше, что именно, где и как делал пользователь, а также отчего могло бы быть конкретное исключение.

a> If you really need to throw your own exception in a catch block, the best way to do this is to throw a new exception and include the old one as the inner exception:

a>

a> try
a> {
a>     // some logic here
a> }
a> catch (SomeException e)
a> {
a>     // log some more info here
a>     throw new SomeException("descriptive message", e);
a> }
a>

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

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

A>Я все же настоятельно советую прочитать мой пример до конца, а не пытаться угадывать.

Причём тут пример? Мой вопрос был, что вы предлагаете делать? Есть конкретное предложение по улучшению кода?

Здравствуйте, stomsky, Вы писали:
S>Тока скажите честно, ВЫ САМИ такое стали бы использовать????
Сам — стал бы. А зачем полагаться на какие-то внешние библиотеки и DSL, которые работают непрозрачным образом?
Только когда такой код станет некрасивым, имеет смысл пойти по пути дальнейшего улучшения.

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

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

S>Здравствуйте, stomsky, Вы писали:
S>>Тока скажите честно, ВЫ САМИ такое стали бы использовать????
S>Сам — стал бы. А зачем полагаться на какие-то внешние библиотеки и DSL, которые работают непрозрачным образом?
А что сама .NET полностью прозрачна?
Библиотека должна работать без ощибок и я должен понимать как ее использовать, все остальное не должно волновать.
S>Только когда такой код станет некрасивым, имеет смысл пойти по пути дальнейшего улучшения.
Зачем продуцировать "некрасивый код". Решение нужно принять до того как.

S>Вообще, вынужден предупредить: я промышленный код не пишу уже много лет, и на практике подобные идеи не проверял.
Тут у нас похоже наоборот. Теория интересует именно с точки зрения применения на практике.

Давайте все же возвратимся к "задетой" части кода и даже теоретически обсудим что же там неправильного в свете вышесказанного и как
должен выглядет "правильный" код? (Для теории — считаем этот метод частью библиотеки.)

        public bool IsNeedToPayBonus(Context context)
        {
            try
            {
                //...
            }
            catch (Exception e)
            {
                Error(e.Message + e.StackTrace);
                throw;
            }
        }

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

S>Доброго времени суток!

Пара полезных статей на хабре про то, как правильно использовать логгеры:
http://habrahabr.ru/blogs/net/98638/
http://habrahabr.ru/blogs/net/135242/

Здравствуйте, AlexNek, Вы писали:
AN>А что сама .NET полностью прозрачна?
AN>Библиотека должна работать без ощибок и я должен понимать как ее использовать, все остальное не должно волновать.
Я не очень понимаю, к чему ваш вопрос. В коде, который я привёл, есть недостаток — в нём всё ещё явно указано, что именно будет трассироваться.
Зато я знаю, почему в этом коде трассируются 1 и 3, и не трассируется 2:

void DoAnything()
  { 
    Trace(()=>{
      Trace(()=>DoAction1());
      DoAction2();
      Trace(()=>DoAction3());
    });
  }

AN>Давайте все же возвратимся к "задетой" части кода и даже теоретически обсудим что же там неправильного в свете вышесказанного и как
AN>должен выглядет "правильный" код? (Для теории — считаем этот метод частью библиотеки.)
AN>

AN>        public bool IsNeedToPayBonus(Context context)
AN>        {
AN>            try
AN>            {
AN>                //...
AN>            }
AN>            catch (Exception e)
AN>            {
AN>                Error(e.Message + e.StackTrace);
AN>                throw;
AN>            }
AN>        }
AN>

А в чём именно тут вопрос? Какую проблему вы хотите решить?

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

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

Я вот тут на днях послушал Радио-Т, и там обсуждали концепцию just in time logging, согласно которой настроить уровни логирования недостаточно для локализации ошибок. Ну положим, у вас есть много Trace, Info, Debug сообщений на сервере, который обрабатывает постоянно новые данные. И вы поступаете обычно так — либо разрешаете писать в лог все-все-все, либо ограничиваете мин. левел Warn и Error. Проблема первого способа — избыточность логируемой инфы. Проблема второго — недостаточность (например, произошла ошибка, сообщение о ней записано в лог, но разобраться, ПОЧЕМУ эта ошибка произошла — без записей Trace, Debug и Info, относящихся к последней выполненной операции, сложно. А вы их заблаговременно отключили).

Вот здесь http://pragprog.com/magazines/2011-12/justintime-logging автор предлагает использовать концепцию, в которой мы можем определить логический "кусок" программы, который занимается некоторой операцией. Мы наваливаем туда все, что можно — Trace, Debug, Info итд, но пока операция не завершится, эта штука не будет записана в лог, она просто хранится в памяти. И после завершения операции мы должны определить, нужно ли целиком все это богатство записать на диск (например в случае ошибки) или можно с чистой совестью выкинуть детали происшедшего. Таким образом, сохраняется баланс между количеством и качеством логируемой информации. Предложенная реализация, конечно, там скудновата, я вот как раз собираюсь для NLog сделать адаптер с более широкой функциональностью. Но идея вот такая. Я бы от себя добавил, что лучше конечно сделать это не в хешмапе, а в древовидной структуре, где узел дерева определяет "область видимости" текущего лог-узла. Ну и сделать эти "узлы" IDisposable, чтобы обязать юзера завершать эти "блоки" логов. Подход мне кажется достаточно перспективным именно в местах, где происходит циклическая обработка потока данных, где важно уметь именно расследовать причины ошибок. В остальных местах можно пользоваться старыми способами, не требующими мозговых затрат на продумывания дерева scope'ов.

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

S> AN>А что сама .NET полностью прозрачна?
S> AN>Библиотека должна работать без ошибок и я должен понимать как ее использовать, все остальное не должно волновать.

S> Я не очень понимаю, к чему ваш вопрос. В коде, который я привёл, есть недостаток — в нём всё ещё явно указано, что именно будет трассироваться.

Это не вопрос а просто комментарий к данной фразе
"S>Сам — стал бы. А зачем полагаться на какие-то внешние библиотеки и DSL, которые работают непрозрачным образом?"
S> Зато я знаю, почему в этом коде трассируются 1 и 3, и не трассируется 2:
S>

S> void DoAnything()
S>   {
S>     Trace(()=>{
S>       Trace(()=>DoAction1());
S>       DoAction2();
S>       Trace(()=>DoAction3());
S>     });
S>   }
S>

Делать код хорошо пригодный для определенного способа трассировки???
S> AN>Давайте все же возвратимся к "задетой" части кода и даже теоретически обсудим что же там неправильного в свете вышесказанного и как
S> AN>должен выглядет "правильный" код? (Для теории — считаем этот метод частью библиотеки.)
S> AN>

S> AN>        public bool IsNeedToPayBonus(Context context)
S> AN>        {
S> AN>            try
S> AN>            {
S> AN>                //...
S> AN>            }
S> AN>            catch (Exception e)
S> AN>            {
S> AN>                Error(e.Message + e.StackTrace);
S> AN>                throw;
S> AN>            }
S> AN>        }
S> AN>

S> А в чём именно тут вопрос? Какую проблему вы хотите решить?
Только прояснить данное сообщение
здесь

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

"Не делайте так. Происходит потеря информации о месте возникновения исходного исключения."
Елинственная связь с этим
здесь

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

это "throw;"

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

AN>Делать код хорошо пригодный для определенного способа трассировки???
Я не понимаю ваш вопрос. Сформулируйте его так, чтобы на него можно было ответить.

S>> А в чём именно тут вопрос? Какую проблему вы хотите решить?
AN>Только прояснить данное сообщение
AN>здесь

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

AN>"Не делайте так. Происходит потеря информации о месте возникновения исходного исключения."
AN>Елинственная связь с этим
AN>здесь

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

AN>это "throw;"
В сообщении, на которое вы ссылаетесь, нет цитаты, которую вы приводите.

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

E>Вот здесь http://pragprog.com/magazines/2011-12/justintime-logging автор предлагает использовать концепцию, в которой мы можем определить логический "кусок" программы, который занимается некоторой операцией. Мы наваливаем туда все, что можно — Trace, Debug, Info итд, но пока операция не завершится, эта штука не будет записана в лог, она просто хранится в памяти. И после завершения операции мы должны определить, нужно ли целиком все это богатство записать на диск (например в случае ошибки) или можно с чистой совестью выкинуть детали происшедшего. Таким образом, сохраняется баланс между количеством и качеством логируемой информации.

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

E>я вот как раз собираюсь для NLog сделать адаптер

с буфером в памяти?

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

OE>во, до этой идеи я тоже додумался, но тут есть существенный затык — если буфер хранить в памяти, то в случае аварийного завершения программы по какой-либо причине мы об этой причине вообще ничего не узнаем, т.к. весь этот буфер просто гикнется вместе с программой, а если этот буфер хранить где-то снаружи (файл, БД), то нет никакого выигрыша в производительности и основной лог и причина падения программы получается лежат в разных местах.
Да проблема-то скорее не в производительности программы, а в производительности анализирующего. Когда тебе надо отпарсить гигабайты логов для поиска единственного исключения — вот это дупа.
Я в своё время думал про что-то типа адаптивного логгирования, когда мы логаем вроде бы всё, но оперативно выбрасываем всё, кроме нужного куска.

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

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

E>>Вот здесь http://pragprog.com/magazines/2011-12/justintime-logging автор предлагает использовать концепцию, в которой мы можем определить логический "кусок" программы, который занимается некоторой операцией. Мы наваливаем туда все, что можно — Trace, Debug, Info итд, но пока операция не завершится, эта штука не будет записана в лог, она просто хранится в памяти. И после завершения операции мы должны определить, нужно ли целиком все это богатство записать на диск (например в случае ошибки) или можно с чистой совестью выкинуть детали происшедшего. Таким образом, сохраняется баланс между количеством и качеством логируемой информации.

OE>во, до этой идеи я тоже додумался, но тут есть существенный затык — если буфер хранить в памяти, то в случае аварийного завершения программы по какой-либо причине мы об этой причине вообще ничего не узнаем, т.к. весь этот буфер просто гикнется вместе с программой, а если этот буфер хранить где-то снаружи (файл, БД), то нет никакого выигрыша в производительности и основной лог и причина падения программы получается лежат в разных местах.

В дотнетовых приложениях прям совсем уж падений не бывает же (кроме падений в нативном коде или если сервер/процесс прибили), а Unhandled exceptions можно отловить и сбросить все, что находилось в буфере перед смертью. Собственно, так я и планирую делать. Ну а если есть куски, в которых это неприемлемо, то по идее можно реализовать схему с постоянным дампом на диск в виде журнала (подобно тому как это делают базы данных), но имхо это ненужное усложнение. Проще в критических местах тогда забить и использовать традиционную схему логирования.

E>>я вот как раз собираюсь для NLog сделать адаптер

OE>с буфером в памяти?

угу

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

S> AN>Делать код хорошо пригодный для определенного способа трассировки???

S> Я не понимаю ваш вопрос. Сформулируйте его так, чтобы на него можно было ответить.
Это было скорее вопросительное замечание, чем вопрос. Но вообще этот код хорошо бы смотрелся только в курсовой по программированию, как мне кажется.

S> S>> А в чём именно тут вопрос? Какую проблему вы хотите решить?

S> AN>Только прояснить данное сообщение
S> AN>здесь

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

S> AN>"Не делайте так. Происходит потеря информации о месте возникновения исходного исключения."
S> AN>Елинственная связь с этим
S> AN>здесь

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

S> AN>это "throw;"

S> В сообщении, на которое вы ссылаетесь, нет цитаты, которую вы приводите.
Сорри ссылки не проверил и забыл что здесь нужно ссылки на сообщения по другому "красть"
Вот эти должны быть правильнее.
http://www.rsdn.ru/forum/dotnet/4641286.1.aspx

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

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

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

Здравствуйте, 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

Не знаю, почему вы хотите пояснений мнению, высказанному abibok-ом, от меня.
Лично у меня по поводу того фрагмента мнений два:
1. К сожалению, в дотнете нет способа перевыбросить исключение, не исказив его стек. Поэтому вариантов для конкретного фрагмента, в общем-то, нет.
2. Но в целом надо понять, а зачем вообще код конкретно этого уровня заморачивается логгированием исключения? Он не доверяет вызывающему коду, думая что тот обязательно исключение проглотит? Он не доверяет вызываемому коду, думая, что тот ничего не протрассирует перед моментом выброса исключения?
Выглядит очень подозрительно. Одно дело, если бы перехват исключения был частью логики. Но тогда бы не было перевыброса. А логгированием исключений должен заниматься специальный код, отдельный от бизнес-логики.

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

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

AN>>Это было скорее вопросительное замечание, чем вопрос. Но вообще этот код хорошо бы смотрелся только в курсовой по программированию, как мне кажется.
S>Если вы хотите какого-то ответа на ваше вопросительное замечание, то, пожалуйста, сделайте его более развёрнутым.
Если бы я хотел "обязательный" ответ, то это был бы вопрос.

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-ом, от меня.
Вообще это я понял (что авторы разные) только когда искал ссылки, обычно я "вижу" форум в "плоском" виде.
S>Лично у меня по поводу того фрагмента мнений два:
S>1. К сожалению, в дотнете нет способа перевыбросить исключение, не исказив его стек. Поэтому вариантов для конкретного фрагмента, в общем-то, нет.

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