Стратегии обработки ошибок в общей библиотеке - C

Question

Я пишу кросс-платформенную разделяемую библиотеку (.so в Linux и .dll в Windows), используя C. В настоящее время при возникновении ошибки библиотечные функции возвращают правильный код ошибки и записывают информацию об ошибке в stderr , Библиотечные функции также выдают некоторую информацию и сообщения отладки на stdout. Это хорошо работает для консольных клиентов.

Теперь в этой библиотеке будут клиентские программы, использующие графический интерфейс, запрограммированный с использованием C ++ и wxWidgets. Мне интересно, каковы будут лучшие методы обработки ошибок и уведомления об этом? Может ли приложение пользовательского интерфейса получать доступ к данным, поступающим в stdout и stderr на всех платформах?

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

Мне интересно, каков был бы очевидный способ решить эту проблему? Любая помощь будет великолепна.

Answer 1

Рекомендуется, чтобы библиотека не печатала что-либо на stderr (или stdout), потому что они могут даже не присутствовать. В дополнение к ситуации с графическим интерфейсом у вас также есть вариант использования серверного приложения, у которого нет «консоли», и вы можете захотеть регистрировать ошибки, используя такую ​​функцию, как syslog ().

Некоторые подходы к обработке информации об ошибках без ее прямой печати:

• возвращает числовой код ошибки и предоставляет функцию для преобразования его в строку

• возвращает код ошибки структуры / объекта, который содержит дополнительную информацию

• предоставляет функцию для объекта "сеанс", которая возвращает информацию о последней ошибке

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

Единственное исключение из правила "не записывать в stderr из библиотеки", с которым мне вполне комфортно, заключается в том, что в библиотеке есть параметр "режим отладки", который позволяет записывать подробную информацию в stderr.

Answer 2

Как правило, вы вообще не должны писать в stdout из своей библиотеки - даже в консольном приложении, которое может повредить вывод, который генерирует приложение. stderr немного более простительно, но вы все равно не должны использовать это, если приложение не запрашивает его.

OpenSSL - это кроссплатформенная разделяемая библиотека, для решения которой пришлось решить практически ту же проблему. В их методе есть запись в библиотеке подробных сведений об ошибках во внутренней очереди ошибок, которую приложение может запросить, когда возвращаемое значение ошибки замечено, а затем представлено пользователю любым подходящим способом. (Он также предоставляет вспомогательную функцию, которая выводит всю очередь ошибок в FILE *).

Answer 3

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

Для возврата ошибок у вас есть три основных стратегии:

1. возвращает код ошибки и имеет функцию, которая переводит его в сообщение
2. передать параметр указателя, который указывает на объект, который будет содержать информацию сообщения об ошибке
3. Иметь некоторый объект глобальной библиотеки, который содержит информацию об ошибке из последней операции.

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

Я бы, наверное, выбрал в основном 2.

Answer 4

В Linux вместо вывода ошибки на стандартный вывод (или стандартную ошибку) вы должны регистрировать ошибку, используя rsyslog . Поскольку вы имеете дело с GUI, возможно, вы также можете открыть окно сообщения (не всегда).

Понятия не имею об окнах, но думаю, что-то похожее.