Обработка ошибок / регистрация ошибок в C ++ для библиотеки / приложения

Question

В течение многих лет я часто сталкивался со следующей проблемой:

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

• Как наше собственное приложение, так и предположительно то, которое пользователи создают с помощью базовой библиотеки, вероятно, будут запускаться как в пакетном режиме (автономно, по сценарию, удаленно и / или из командной строки), так и в интерактивном режиме. .

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

• Для некоторых из них (возможно, только очень серьезных) может потребоваться диалоговое окно, если они запускаются в интерактивном режиме; но он должен войти без остановки для пользовательского ввода при запуске в пакетном режиме; и если программа запускается как библиотека, клиентская программа, очевидно, хочет перехватить и / или изучить ошибки по мере их возникновения.

• Все это должно быть кроссплатформенным: Linux, Windows, OSX. И мы хотим, чтобы решение не было странным на любой платформе. Например, вывод в stderr подходит для Linux, но не работает в Windows при подключении к приложению с графическим интерфейсом.

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

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

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

У кого-нибудь есть мудрость относительно того, как интегрировать эту функциональность в API C ++, или есть принятая парадигма или хорошее решение с открытым исходным кодом (не GPL, пожалуйста, я хотел бы использовать решение, которое я могу использовать в коммерческих закрытых приложениях, ну как проекты OSS)?

Answer 1

Log4Cxx должен работать на вас. Вам необходимо реализовать провайдера, который позволит пользователю библиотеки перехватывать выходные данные журнала в обратных вызовах. Библиотека будет экспортировать функцию для установки обратных вызовов. Эта функция должна за кулисами перенастроить log4cxxx, чтобы избавиться от всех добавителей и настроить «настраиваемый» добавитель.

Конечно, у пользователя библиотеки есть возможность не устанавливать обратные вызовы и использовать log4cxx как есть.

Answer 2

Мы используем Apache Log4cxx для ведения журналов, которые не идеальны, но обеспечивают большую инфраструктуру и последовательный подход к проектам. Я считаю, что он кроссплатформенный, хотя мы используем его только в Windows.

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

Если клиенты вашей библиотеки также примут его, то они интегрируют свои выходные данные в один и тот же файл журнала.

Различие между экземплярами основного класса может поддерживаться с помощью функции вложенного диагностического контекста (NDC).