Здравствуйте.
Хорошая ли практика писать тексты лога и ошибок прямо в коде программы? Плюсы и минусы обоих подходов мне понятны, но какой подход выбрали бы вы, если, например, начинали писать какую-то систему с нуля?
Взять те же исключения. Очень удобно и просто написать

if (error)
  throw(exception("You got some error"));
if (other_error)
  throw(exception("You got some other error"));

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

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

W>Хорошая ли практика писать тексты лога и ошибок прямо в коде программы? Плюсы и минусы обоих подходов мне понятны, но какой подход выбрали бы вы, если, например, начинали писать какую-то систему с нуля?

Тексты — быстрый старт, мрачный рефакторинг.
Идентификаторы — тяжёлый старт.

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

Как вариант, идея

// user_defined_exceptions.h
enum UserDefinedException
{
  // единый стиль именования - ALL_CAPS
  // все виды ошибок сосредоточены в одном месте
  YOU_GOT_SOME_ERROR,
  YOU_GOT_SOME_OTHER_ERROR,
};

template<UserDefinedException> class user_defined_exception : public exception
{
public:
  user_defined_exception(string what) : exception(what) {}
};

#define USER_DEFINED_EXCEPTION(id) (user_defined_exception<id>(#id))
#define USER_DEFINED_EXCEPTION_EX(id,msg) (user_defined_exception<id>(string(#id) + " : " + msg))

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

W>Может ли потребоваться локализация сообщений об ошибках?

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

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

W>Хорошая ли практика писать тексты лога и ошибок прямо в коде программы?

Зависит от того, кто будет читать. Если сам разработчик, то нормальная, на мой взгляд.

W>да и поддерживать какой-то единый стиль оформления сложно — кто-то пишет с большой буквы, кто-то — с маленькой, кто-то ставит точку, кто-то нет, и т.п.

Стандарты кодирования + код-ревью

По поводу 1)
W>но потом возникают проблемы с перехватом конкретных исключений

и 2)
W>В бусте, насколько я помню, есть просто код ошибки в исключении, и когда ловишь его, понять в чем конкретно ошибка оказывается очень непросто. Нужно листать документацию, или искать в комментарииях. Да и через такой механизм не протащишь какие-то дополнительные данные об ошибке.

Если такие проблемы (1) и (2) возникли, я бы таки ввел некую иерархию исключений (some_error и some_other_error). Обе проблемы тогда магически исчезают, новых я не предвижу.

W>Может ли потребоваться локализация сообщений об ошибках?

Локализация сообщений об ошибках, разумеется, может понадобиться.

Вот что пишут бюстовцы по этому поводу:

5. Don't worry too much about the what() message. It's nice to have a message that a programmer stands a chance of figuring out, but you're very unlikely to be able to compose a relevant and user-comprehensible error message at the point an exception is thrown. Certainly, internationalization is beyond the scope of the exception class author. Peter Dimov makes an excellent argument that the proper use of a what() string is to serve as a key into a table of error message formatters. Now if only we could get standardized what() strings for exceptions thrown by the standard library...

Но на деле в бусте тот еще зоопарк с исключениями, и никакого общего стиля нет (кто-то наследуется от exception виртуально, кто-то нет; кто-то форматирует what() по требованию, кто-то просто вставляет string, и т.п.)

W>какой подход выбрали бы вы, если, например, начинали писать какую-то систему с нуля?

На практике, мы, например, пишем серверные приложения, и нам хватает незатейливых runtime_error для 5xx ошибок и logic_error для 4xx.
Никакой локализацией соответствующих сообщений пока не озаботились.

Спасибо за ответы. Буду продумывать детали.

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

AP>5. Don't worry too much about the what() message.

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