Was ich immer noch nicht richtig zuordnen kann ist deine Sorge um Return values die der Nutzer vielleicht nicht auswertet und glaubt ein richtiges Ergebnis zu haben. Und glauben die Library sei fehlerhaft und "nicht gut". So etwas ist mir persönlich völlig fremd.
Das nicht-Auswerten von Fehlercodes ist leider ziemlich häufig - wobei dieser Punkt auch eher nur ein kleines Contra ist. Der zweite Teil bezieht sich auf Assertions. Hier würde es ja dann innerhalb der Library crashen und da gehen manche Entwickler hin und behaupten einfach, dass alles was nicht in ihrem eigenen Code crasht, ein Bug in der Library sein muss. Absolut dämlich, ich weiß.
Ich würde, beispielsweise bei einem negativen
Handle einen ordentlich dokumentierten Fehlercode zurückgeben.
Okay danke, das entspricht ja dann meiner Variante (2), die ich auch momentan verwende.
Exceptions gibt es im C auch, nur kennt C natürlich die Delphi-Exceptionklassen nicht und kann da dann nichtmal den im unbekannten Message-Text auswerten.
Leider nein. Der C Standard sieht keine
Exception-Behandlung vor. CPU-Exceptions existieren natürlich weiterhin, aber man kann sie nicht Plattform-/Architektur-unabhängig fangen. Im Falle von C++ hast du Recht (ich verwende allerdings tatsächlich pures C im konkreten Falle).
Nja, du kannst natürlich auch LongBool-Results nehmen (in C++ ist der BOOL gern 32 Bit groß),
definierst dir eine Reihe Fehlercodes, nach dem Muster der
WinAPI, wie z.B. HRESULT,
und nutzt fleißig
SetLastError. (natürlich nur wenn es auch einen Fehler gab, also nur bei Result=False)
Danke dir, das entspricht ja auch meiner Variante (2). Die konkrete Umsetzung ist mir noch gar nicht so wichtig im Moment. Mir geht es eher um die Grundsatzdiskussion Assertions vs. "richtigen" Checks und den damit verbundenen (theoretischen) Vor- und Nachteilen.