DLL/Lib: Parameter Validierung

[Zacherl]

Zitat von Der schöne Günther:

Kannst du denn ein abstraktes Beispiel geben? Mir fehlt dazu die Vorstellungskraft. Holt man sich bei deiner APIs denn auch Bezeichner wie z.B. Handles ab und übergibt die später anderen Routinen?

Ja, im Grunde genau so.

Wobei das auch nicht wirklich einen Unterschied macht, da die Fragestellung z.B. auch auf eine einfache Wurzel-Funktion anwendbar ist. Sagen wir ich habe einen Algorithmus, der die Wurzel einer Zahl berechnet und der auch für negative Zahlen ein (sinnloses) Ergebnis liefert. Prüfe ich jetzt per Assertion auf Zahlen < 0 oder implementiere ich einen "richtigen" Check, der ggfls. einen Error-Code zurückgibt? Oder kombiniere ich sogar beide Varianten?

Im Falle der Assertion kann es sein, dass der Programmierer meine Funktion immer nur mit positiven Zahlen füttert, der Endanwender aber etwas Negatives übergibt und somit ein unerwartetes Ergebnis bekommen würde (wenn der Entwickler nicht manuell die Benutzereingabe vorher validiert, bevor er sie meiner Funktion übergibt).

Mit Runtime-Checks würde die - zur Entwicklungszeit nicht getestete - Eingabe dazu führen, dass eine Fehlermeldung angezeigt wird (vorrausgesetzt der Entwickler prüft den Error-Code).

Zitat von himitsu:

Dafür sind grade Assertions da, dass man sie deakivieren kann, damit es schneller geht. Aber wenn man sie deaktiviert, dann hat man auch mit Fehlerverhalten zu rechnen, wenn die Eingaben doch ma nicht stimmen.
Also ist es IMHO sinnlos und kontraproduktiv, wenn zusätzlich noch eine zweite Eingangsprüfung vorhanden wäre.

Mhh, aber dass Assertions im Release Modus aktiviert bleiben, ist (aus gutem Grunde denke ich) in praktisch keiner Standardkonfiguration gegeben. Die zusätzlichen Checks (3) wären ausschließlich hierfür gedacht, um undefiniertes Verhalten im Produktivbetrieb zu vermeiden, auch wenn mal ein Fehler während der Entwicklung nicht erkannt wurde (siehe z.B. das obige Beispiel der Wurzelfunktion).

Zitat von himitsu:

Und meistens nehme ich inzwischen Exceptions, zur Fehlerbehandlung, anstatt einem Fehlercode-Result.

Ah, ja guter Punkt. Ich hätte vielleicht im Anfangspost erwähnen sollen, dass es sich im Speziellen grade um eine C-Library handelt (also keine Exceptions existieren).

Zitat von himitsu:

Zitat:

Contra:
* Assertions lassen sich abschalten

Das ist doch eher ein Pro, für den Entwickler.