Fehlerbehandlungsstrategien in einer gemeinsam genutzten Bibliothek - C

Question

Ich schreibe eine plattformübergreifende gemeinsame Bibliothek ( .so unter Linux und .dll in Windows) unter Verwendung von C. Wenn ein Fehler auftritt, geben die Bibliotheksfunktionen den entsprechenden Fehlercode zurück und schreiben die Fehlerinformationen in die stderr . Die Bibliotheksfunktionen geben auch einige Informationen und Debug-Meldungen an stdout . Dies funktioniert gut für konsolenbasierte Clients.

Diese Bibliothek wird nun Client-Programme haben, die eine mit C++ und wxWidgets programmierte GUI verwenden. Ich frage mich, was die besten Praktiken bei der Behandlung von Fehlern und deren Benachrichtigung sind? Kann eine UI-Anwendung auf Daten zugreifen, die an stdout y stderr auf allen Plattformen?

Eine alternative Möglichkeit, die ich dachte, ist die Bibliothek Initialisierungsfunktion initialisiert eine Struktur, die Funktion Zeiger haben wird. Alle Funktionen der Bibliothek werden eine Instanz dieser Struktur nehmen und die Funktionszeiger aufrufen. Auf diese Weise kann der Kunde wählen, wo die Nachrichten gedruckt werden sollen.

Ich frage mich, was die naheliegendste Lösung für dieses Problem wäre? Jede Hilfe wäre großartig.

Answer 1

Die beste Praxis (IMHO) ist, dass eine Bibliothek nichts auf stderr (oder stdout) ausgibt, da diese möglicherweise gar nicht vorhanden sind. Neben der GUI-Situation gibt es auch den Anwendungsfall einer Serveranwendung, die keine "Konsole" hat und möglicherweise Fehler mit einer Funktion wie syslog() protokollieren möchte.

Einige Ansätze zur Behandlung von Fehlerinformationen, ohne sie direkt zu drucken:

• einen numerischen Fehlercode zurückgeben und eine Funktion bereitstellen, die diesen in eine Zeichenkette umwandelt

• einen Struktur/Objekt-Fehlercode zurückgeben, der zusätzliche Informationen enthält

• eine Funktion für ein "Session"-Objekt bereitstellen, die Informationen über den letzten Fehler zurückgibt

• dem Aufrufer erlauben, einen Rückruf zu registrieren, der im Falle eines Fehlers aufgerufen wird

Die einzige Ausnahme von der Regel "schreibe nicht von einer Bibliothek nach stderr", mit der ich einigermaßen einverstanden bin, ist, wenn eine Bibliothek einen "Debug-Modus"-Parameter hat, der die Protokollierung von detaillierten Informationen nach stderr ermöglicht.

Answer 2

Im Allgemeinen sollten Sie nicht schreiben, um stdout überhaupt nicht aus Ihrer Bibliothek verwenden - auch nicht in einer Konsolenanwendung, da dies die von der Anwendung erzeugte Ausgabe verfälschen könnte. stderr ist ein wenig verzeihlicher, aber man sollte es trotzdem nicht verwenden, es sei denn, die Anwendung verlangt es.

OpenSSL ist eine plattformübergreifende, gemeinsam genutzte Bibliothek, die ein ähnliches Problem zu lösen hatte. Ihre Methode sieht vor, dass die Bibliothek detaillierte Fehlerinformationen in einer internen Fehlerwarteschlange aufzeichnet, die die Anwendung beim Auftreten eines Fehlerrückgabewerts anfordern und dann dem Benutzer in geeigneter Weise präsentieren kann. (Sie bietet auch eine Komfortfunktion, die die gesamte Fehlerwarteschlange in eine FILE * ).

Answer 3

Für Protokollnachrichten sollten Sie dem Client die Möglichkeit geben, der Bibliothek eine Callback-Funktion zur Verfügung zu stellen, damit der Client entscheiden kann, was mit ihnen geschehen soll, z. B. Senden an syslog oder Anzeigen in einem Fenster auf dem Bildschirm.

Für die Rückgabe von Fehlern gibt es drei grundlegende Strategien:

1. einen Fehlercode zurückgeben und über eine Funktion verfügen, die diesen in eine Meldung umwandelt
2. einen Zeiger-Parameter übergeben, der auf ein Objekt zeigt, das Fehlermeldungsinformationen enthält
3. Sie haben ein globales Bibliotheksobjekt, das die Fehlerinformationen der letzten Operation enthält.

In jedem Fall sollten Sie die Fehlermeldung nicht einfach protokollieren, da der Client möglicherweise etwas damit anfangen möchte, z. B. ein Dialogfeld anzeigen.

Ich würde wahrscheinlich hauptsächlich mit 2 gehen.

Answer 4

Unter Linux sollten Sie den Fehler nicht auf der Standardausgabe (oder dem Standardfehler) ausgeben, sondern den Fehler mit rsyslog . Da Sie es mit einer grafischen Benutzeroberfläche zu tun haben, können Sie vielleicht auch ein Meldungsfenster einblenden (nicht immer).

Ich habe keine Ahnung von Windows, aber ich glaube, es hat etwas Ähnliches.