共享库中的错误处理策略 - C
我正在使用 C 编写一个跨平台共享库（linux 中的 .so 和 windows 中的 .dll）。目前，当出现错误时，库函数会返回正确的错误代码并将错误信息写入stderr。库函数还会向 stdout 发出一些信息和调试消息。这对于基于控制台的客户端非常有效。
现在这个库将拥有使用使用 C++ 和 C++ 编程的 GUI 的客户端程序。 wxWidgets。我想知道处理错误并通知错误的最佳实践是什么？ UI 应用程序是否可以访问所有平台上的 stdout 和 stderr 数据？
我想到的另一种方法是库初始化函数初始化一个具有函数指针的结构。库中的所有函数都将采用该结构的实例并调用函数指针。这样客户端就可以选择打印消息的位置。
我想知道解决这个问题的明显方法是什么？任何帮助都会很棒。
I am writing a cross platform shared library (.so in linux and .dll in windows) using C. Currently when there is a error, library functions returns the proper error code and writes error information into the stderr. Library functions also emits some information and debug messages to stdout. This works well for console based clients.
Now this library will have client programs that uses GUI programmed using C++ & wxWidgets. I am wondering what would be the best practices in handling the errors and notifying it? Can a UI application access data coming to stdout and stderr on all platforms?
An alternative way I was thinking is the library initialization function initializes a structure which will have function pointers. All the functions on the library will take an instance of this structure and call the function pointers. This way the client can choose where to print the messages.
I am wondering what would be the obvious way to solve this? Any help would be great.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
最佳实践（恕我直言）是库不要将任何内容打印到 stderr （或 stdout），因为它们甚至可能不存在。除了 GUI 情况之外，您还拥有没有“控制台”的服务器应用程序的用例，并且可能希望使用 syslog() 等函数来记录错误。
处理错误信息而不直接打印的一些方法：
返回数字错误代码，并提供将其转换为字符串的函数
返回一个结构/对象错误代码，其中包含附加信息
在“会话”对象上提供一个函数，该函数返回有关最后一个错误的信息
允许调用者注册在发生错误时调用的回调
我相当满意的“不要从库写入 stderr”规则的一个例外是，如果库具有“调试模式”参数，可以将详细信息记录到 stderr 。
Best practice (IMHO) is for a library to not print anything to stderr (or stdout), because they may not even be present. In addition to the GUI situation, you also have the use case of a server application that doesn't have a "console", and may want to be logging errors using a function like syslog().
Some approaches for handling error information without printing it directly:
return a numeric error code, and provide a function for turning it into a string
return a struct/object error code, which contains additional information
provide a function on a "session" object that returns info about the last error
allow the caller to register a callback that's invoked in the event of an error
The one exception to the "don't write to stderr from a library" rule that I'm reasonably comfortable with is if a library has a "debug mode" parameter that enables logging of detailed info to stderr.
一般来说，您根本不应该从库中写入
stdout- 即使在可能会破坏应用程序生成的输出的控制台应用程序中也是如此。stderr更容易被原谅，但除非应用程序请求，否则您仍然不应该真正使用它。OpenSSL 是一个跨平台共享库，也有很多相同的问题需要解决。他们的方法让库在内部错误队列中记录详细的错误信息，应用程序可以在看到错误返回值时请求这些信息，然后以适当的方式呈现给用户。 （它还提供了一个方便的功能，将整个错误队列转储到
FILE *）。In general, you shouldn't be writing to
stdoutat all from your library - even in a console application that could corrupt the output that the application is producing.stderris a little more forgivable, but you still shouldn't really use that unless the application requests it.The OpenSSL is a cross-platform shared library that had much the same problem to solve. Their method has the library record detailed error information in an internal error queue, which the application can request when an error return value is seen and then present to the user in whichever way is appropriate. (It also provides a convenience function that dumps the entire error queue to a
FILE *).对于日志消息，您应该允许客户端向库提供回调函数，以便客户端可以决定如何处理它们，例如发送到系统日志或显示在屏幕上的窗口中。
对于返回错误，您可以采用三种基本策略：
无论您做什么，您都不想只记录错误消息，因为客户端可能想用它做一些事情。例如呈现一个对话框。
我可能会选择 2 个。
For log messages, you should allow the client to supply a callback function to the library so then the client can decide what to do with them e.g. send to syslog or display in a window on the screen.
For returning errors, you have three basic strategies:
Whatever you do, you don't want to just log the error message because the client might want to do something with it. e.g. present a dialog box.
I'd probably go with 2 mostly.
在 Linux 上，您应该使用 记录错误，而不是在标准输出（或标准错误）上打印错误rsyslog。由于您正在处理 GUI，也许您还可以弹出一个消息框（并非总是如此）。
我对窗户一无所知，但我认为它有类似的东西。
On linux, instead of printing the error on standard output (or standard error), you should log the error using rsyslog. Since you are dealing with GUI, maybe you can also pop a message box (not always).
I have no idea about the windows, but I think it has something similar.