Пустые дебаг методы vs полное выпиливание с проекта

@rikimaru2013 · Регистрация: 30.11.2013

Author24 — интернет-сервис помощи студентам

Добрый вечер,

C++

#include <string>
using namespace std;
 
//////////////////////////////////////////////////////////////////////////
class Log1
{
public:
    static void log(const std::string&)
    {
#if !defined(PRODUCTION)
        // ...
#endif
    }
};
 
//////////////////////////////////////////////////////////////////////////
 
//////////////////////////////////////////////////////////////////////////
class Log2
{
#if !defined(PRODUCTION)
public:
    static void log(const std::string&)
    {
    
    }
 
#endif
};
 
#if !defined(PRODUCTION)
#define LOG(str) Log2::log(str)
#else
#define LOG(str)
#endif
 
//////////////////////////////////////////////////////////////////////////
 
int main()
{
    Log1::log("123213");
    LOG("123123123");
}

Подскажите, какой способ лучше применять для вещей которые не должны попасть в продакшен, и разбросаны по всему коду?

Моё мнение:
если макрос - то особо не поиграться с шаблонами и отсутствие статического проверки типа
если методы пустышки - то будет ли создаваться под них стек и вызов, или компилятор с оптимизирует всё это дело?

MrGluck · 28.01.2017, 23:29

Сообщение от rikimaru2013

а почему у каждого клиента свой сервер?)

Потому что мы поставляем клиент-серверное приложение. Почему вас это смутило?

@rikimaru2013 · 28.01.2017, 23:38 **[ТС]**

Сообщение от MrGluck

Почему вас это смутило?

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

Убежденный · 29.01.2017, 10:55

Сообщение от sys_beginner

это как правило означает, что программист что-то упустил. А в случае с логами это как раз те участки, которые заранее известны (программист же руками не зря в этом участке ведет логирование). Как можно залогировать то, о чем программист просто не подозревает, как ты сам отметил "работает не так как было задумано". Если ошибка в самой программе, то логи об этом не скажут.

Я не соглашусь. Категорично.

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

NDSrv [I] registerDevice: status = OK.
NDSrv [I] createWorkerPool: numThreads = 8
NDSrv [I] createConnection: addr = 10.0.64.152, port = 80
NDSrv [I] delegateWork: thread = 1
NDSrv [I] thread(1): 973 bytes received, calling handler...
NDSrv [I] thread(1): 973 bytes received, calling handler...
NDSrv [I] thread(1): 973 bytes received, calling handler...
NDSrv [I] thread(1): 973 bytes received, calling handler...
NDSrv [I] thread(1): 973 bytes received, calling handler...
NDSrv [I] thread(1): 973 bytes received, calling handler...
NDSrv [I] thread(1): 973 bytes received, calling handler...
...

Здесь видно, что до вызова delegateWork все было в порядке, после чего обработчик потока
почему-то стал рекурсивно вызывать сам себя. Одинаковое количество принятых байт еще
больше усиливает подозрение. Логи нам не скажут, что кто-то забыл в полиморфный метод
хэндлера добавить ключевое слово virtual. Но они скажут, что надо открывать и смотреть код
delegateWork и функцию thread. Т.е., как минимум, логи здесь помогли очень сильно сузить
круг поисков.

Сообщение от rikimaru2013

странный у вас софт если падает от названия домена и установленного антивируса) Прям вижу уже на обороте диска с игрой системные требование : "не устанавливайте AVAST и не используйте хостинга Trololo"

У нас очень сложный софт, который глубоко интегрируется в систему, местами почище антивирусов.
А у клиентов окружение иногда настолько нестандартное и заковыристое, что бывает всякое.
Иногда проблемы возникают из-за совершенно простых функций, которые до этого годами
использовались и никто не жаловался. Иногда приходится сталкиваться с багами в чужом софте, в
том числе в антивирусных продуктах, или даже в самой ОС.

Разрабатывать софт, который и в таких конфигурациях будет четко работать с железобетонной и
неумолимой логикой, довольно тяжело. "Цветастость" багов зашкаливает, можно книгу писать

@Voivoid · 29.01.2017, 11:06

Сообщение от sys_beginner

Для этого программное обеспечение должно уметь "отлавливать" ошибки

Ага, а настоящий программист должен писать без багов

@Undisputed · 29.01.2017, 12:19

Сообщение от Убежденный

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

Ага, это моя основная мысль.

Сообщение от Убежденный

Но они скажут, что надо открывать и смотреть код
delegateWork и функцию thread. Т.е., как минимум, логи здесьпомогли очень сильно сузить
круг поисков.

Да, именно такие моменты я называю "побочными эффектами", у меня тоже такое бывало, только в 9 из 10 случаев обычно я знал "вот тут мне нужен лог" потому что понимал могут быть проблемы в этом месте и нужно это отслеживать.
Поэтому называть логгер баг хантером ну уж никак язык не поворачивается...

Наверное кому что больше встречалось тот ту сторону и защищает

Сообщение от Voivoid

Ага, а настоящий программист должен писать без багов

)))

@hoggy · 30.01.2017, 12:42

Сообщение от sys_beginner

Почему бинарь отлаживать?

вы вообще когда нибудь имели дело с боевым проектом?

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

ну и что вы будете делать?

собирать софтинку на своей локальной машинке?
а не факт, что на локальной машине этот баг вообще воспроизведётся
как и что вы будете отлаживать?

я просто почитаю логи,
и буду знать, что происходило.

Сообщение от sys_beginner

Я имел ввиду, если есть подозрение на баг, берем сорцы и дебажим в дебаг режиме...

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

Сообщение от sys_beginner

Речь шла именно о исправлении багов с помощью логгера(я выступал именно против этого).

именно для исправления ошибок логи и нужны.
что бы что-то исправить, нужно сначала понять:
что именно сломалось.

можно просто почитать текст логов.
а можно поиграть в телепата-нострадамуса.

Сообщение от sys_beginner

Да. Только не каждая ошибка это баг, так ведь?

к чему вообще вопрос?

Сообщение от sys_beginner

А баги это уже заботы дебагера, я об этом.

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

Сообщение от sys_beginner

Ну начнем с того что доступ к удаленному серверу может быть не всегда. Посмотрите например API того же Вконтакте и ему подобных. Обычно такие сервисы предоставляют определенный интерфейс

и какое отношения этот поток сознания имеет к теме логирования?
и да, программисты вконтактика тоже используют логгирование.
внезапно.

Сообщение от sys_beginner

Для этого "реальные пацаны", разработчики серверов обычно предоставляют соответствующий интерфейс общения для тех кто использует API, а не умирают молча (и не виснут в состоянии "???").

аха, и никогда не ошибаются.
и какают, наверное, вишенками.

Сообщение от sys_beginner

В таком случае логгер должен будет решать много задач что в сущности неверно.

он решает одну задачу - логгирует.

логгер ничего не знает о том, что делать в случае краша.
он просто запускает аварийный скрипт.
что в него записал программист - ему фиолетово.

Сообщение от sys_beginner

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

C++

if (criticalProblem) {
    Logger->log(WARN, "error message");
    Mailer->send("developer@gmail.com", Logger->getList()->toString());
    //other operations...
}

вы вообще себя слышите?
это сбой.
процесс уже умер.

@Undisputed · 30.01.2017, 12:53

Сообщение от hoggy

к чему вообще вопрос?

Это был риторический вопрос. Он был к тому, что ошибка может произойти не по причине бага а из за проблем самой машины(например нет места на диске, программа не виновата).

Сообщение от hoggy

он просто запускает аварийный скрипт.

и как он запускает этот скрипт, если

Сообщение от hoggy

это сбой. процесс уже умер.

вы запускаете логгер как отдельный процесс следящий за основным?

Опять же. Там где есть логирование - это место программист залогировал сам ибо понимал что проблемы могут быть в этом месте.
Я же говорю о тех вещах где заранее неизвестно что может возникнуть проблема

@hoggy · 30.01.2017, 13:43

Сообщение от sys_beginner

Он был к тому, что ошибка может произойти не по причине бага а из за проблем самой машины(например нет места на диске, программа не виновата

какая разница?

Сообщение от sys_beginner

вы запускаете логгер как отдельный процесс следящий за основным?

отдельный процесс на каждый тред.

основной процесс сообщает:
"тред номер 1, запускаю функцию foo"
сигнал получает сторожевик данного треда.

он знает, что функция foo грубо говоря выполняется за доли секунды.
если в течении 1 секунды основной процесс не отчитается о том,
что foo успешно выполнена,
сторожевик посчитает процесс в состоянии сбоя.
все сторожевики сохраняют логи.
и запускается аварийный скрипт.

Сообщение от sys_beginner

Там где есть логирование - это место программист залогировал сам ибо понимал что проблемы могут быть в этом месте.
Я же говорю о тех вещах где заранее неизвестно что может возникнуть проблема

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

@Raali · 30.01.2017, 14:36

Не по теме:

Сообщение от hoggy

вы вообще себя слышите?
это сбой.
процесс уже умер.

окончание триллера, виновного в смерти процесса так и не нашли

MrGluck Форумчанин 8215 / 5045 / 1437 Регистрация: 29.11.2010 Сообщений: 13,453
	28.01.2017, 23:29	41
	Сообщение от rikimaru2013 а почему у каждого клиента свой сервер?) Потому что мы поставляем клиент-серверное приложение. Почему вас это смутило? 0

@Voivoid 710 / 283 / 16 Регистрация: 31.03.2013 Сообщений: 1,340
	29.01.2017, 11:06	44
	Сообщение от sys_beginner Для этого программное обеспечение должно уметь "отлавливать" ошибки Ага, а настоящий программист должен писать без багов 0

@Undisputed 875 / 461 / 91 Регистрация: 10.06.2014 Сообщений: 2,669
	29.01.2017, 12:19	45
	Сообщение от Убежденный Логи нам не скажут, что кто-то забыл в полиморфный метод хэндлера добавить ключевое слово virtual. Ага, это моя основная мысль. Сообщение от Убежденный Но они скажут, что надо открывать и смотреть код delegateWork и функцию thread. Т.е., как минимум, логи здесьпомогли очень сильно сузить круг поисков. Да, именно такие моменты я называю "побочными эффектами", у меня тоже такое бывало, только в 9 из 10 случаев обычно я знал "вот тут мне нужен лог" потому что понимал могут быть проблемы в этом месте и нужно это отслеживать. Поэтому называть логгер баг хантером ну уж никак язык не поворачивается... Наверное кому что больше встречалось тот ту сторону и защищает Сообщение от Voivoid Ага, а настоящий программист должен писать без багов ))) 0

@Undisputed 875 / 461 / 91 Регистрация: 10.06.2014 Сообщений: 2,669
	30.01.2017, 12:53	47
	Сообщение от hoggy к чему вообще вопрос? Это был риторический вопрос. Он был к тому, что ошибка может произойти не по причине бага а из за проблем самой машины(например нет места на диске, программа не виновата). Сообщение от hoggy он просто запускает аварийный скрипт. и как он запускает этот скрипт, если Сообщение от hoggy это сбой. процесс уже умер. вы запускаете логгер как отдельный процесс следящий за основным? Опять же. Там где есть логирование - это место программист залогировал сам ибо понимал что проблемы могут быть в этом месте. Я же говорю о тех вещах где заранее неизвестно что может возникнуть проблема 0

@hoggy 8739 / 4317 / 960 Регистрация: 15.11.2014 Сообщений: 9,760
	30.01.2017, 13:43	48
	Сообщение от sys_beginner Он был к тому, что ошибка может произойти не по причине бага а из за проблем самой машины(например нет места на диске, программа не виновата какая разница? Сообщение от sys_beginner вы запускаете логгер как отдельный процесс следящий за основным? отдельный процесс на каждый тред. основной процесс сообщает: "тред номер 1, запускаю функцию foo" сигнал получает сторожевик данного треда. он знает, что функция foo грубо говоря выполняется за доли секунды. если в течении 1 секунды основной процесс не отчитается о том, что foo успешно выполнена, сторожевик посчитает процесс в состоянии сбоя. все сторожевики сохраняют логи. и запускается аварийный скрипт. Сообщение от sys_beginner Там где есть логирование - это место программист залогировал сам ибо понимал что проблемы могут быть в этом месте. Я же говорю о тех вещах где заранее неизвестно что может возникнуть проблема логгирование для того и нужно, что бы выявлять вот эти заранее неизвестные места. 0

@rikimaru2013 2549 / 1208 / 358 Регистрация: 30.11.2013 Сообщений: 3,826
	28.01.2017, 23:38 [ТС]	42
	Сообщение от MrGluck Почему вас это смутило? Не встречал в своей практике приложение, что является сервером в том смысле в каком оно есть для многих. Как правило, это дата-центр с кучей компов, который арендует фирма. Но чтобы клиент установивший ваш софт называл свою комнату серверной? нет. Не встречал. 0

Убежденный Ушел с форума 16473 / 7436 / 1187 Регистрация: 02.05.2013 Сообщений: 11,617 Записей в блоге: 1
	29.01.2017, 10:55	43
	Сообщение от sys_beginner это как правило означает, что программист что-то упустил. А в случае с логами это как раз те участки, которые заранее известны (программист же руками не зря в этом участке ведет логирование). Как можно залогировать то, о чем программист просто не подозревает, как ты сам отметил "работает не так как было задумано". Если ошибка в самой программе, то логи об этом не скажут. Я не соглашусь. Категорично. Да, логи, даже очень подробные и хорошо продуманные, далеко не всегда могут точно указать на функцию и номер строки в ней, в которой произошел сбой. Но они позволяют мысленно проследить ход выполнения программы и дойти до этой точки или хотя бы примерно до того места, где был сбой. Вот пример: при работе сервера один из его рабочих потоков начал грузить процессор и "зациклился", сервер перестал отвечать на команды и пришлось прибить его из диспетчера задач. Вот кусок лога: NDSrv [I] registerDevice: status = OK. NDSrv [I] createWorkerPool: numThreads = 8 NDSrv [I] createConnection: addr = 10.0.64.152, port = 80 NDSrv [I] delegateWork: thread = 1 NDSrv [I] thread(1): 973 bytes received, calling handler... NDSrv [I] thread(1): 973 bytes received, calling handler... NDSrv [I] thread(1): 973 bytes received, calling handler... NDSrv [I] thread(1): 973 bytes received, calling handler... NDSrv [I] thread(1): 973 bytes received, calling handler... NDSrv [I] thread(1): 973 bytes received, calling handler... NDSrv [I] thread(1): 973 bytes received, calling handler... ... Здесь видно, что до вызова delegateWork все было в порядке, после чего обработчик потока почему-то стал рекурсивно вызывать сам себя. Одинаковое количество принятых байт еще больше усиливает подозрение. Логи нам не скажут, что кто-то забыл в полиморфный метод хэндлера добавить ключевое слово virtual. Но они скажут, что надо открывать и смотреть код delegateWork и функцию thread. Т.е., как минимум, логи здесь помогли очень сильно сузить круг поисков. Сообщение от rikimaru2013 странный у вас софт если падает от названия домена и установленного антивируса) Прям вижу уже на обороте диска с игрой системные требование : "не устанавливайте AVAST и не используйте хостинга Trololo" У нас очень сложный софт, который глубоко интегрируется в систему, местами почище антивирусов. А у клиентов окружение иногда настолько нестандартное и заковыристое, что бывает всякое. Иногда проблемы возникают из-за совершенно простых функций, которые до этого годами использовались и никто не жаловался. Иногда приходится сталкиваться с багами в чужом софте, в том числе в антивирусных продуктах, или даже в самой ОС. Разрабатывать софт, который и в таких конфигурациях будет четко работать с железобетонной и неумолимой логикой, довольно тяжело. "Цветастость" багов зашкаливает, можно книгу писать 4

@Raali
	30.01.2017, 14:36 Пустые дебаг методы vs полное выпиливание с проекта #49
	Не по теме: Сообщение от hoggy вы вообще себя слышите? это сбой. процесс уже умер. окончание триллера, виновного в смерти процесса так и не нашли 0