Zitat:
1. Parameter durch Assertions validieren
2. Parameter validieren und ggfls. mit Error-Code returnen
3. Parameter zuerst mit Assertion validieren und als Fallback mit Error-Code returnen
Ich baue grundsätzlich immer nur eine Art der Fehlerprüfung ein und mische nicht. (also fast wie 2)
Maximal wird intern zusätzlich nochmal ein Fehlerflag (ErrorCode/-Text) gespeichert, welchen man nachträglich nochmal prüfen kann, so ala GetLastError.
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. (3)
Und meistens nehme ich inzwischen Exceptions, zur Fehlerbehandlung, anstatt einem Fehlercode-Result.
Dazu definiere ich mir meistens mindestens eine eigene Exceptionklasse, je Library.
Diese Klassen können dann auch Zusatzinfos enthalten, siehe ErrorCode in EOSError oder EInOutError.
Zitat:
Contra:
* Assertions lassen sich abschalten
Das ist doch eher ein Pro, für den Entwickler.
Gerade bei Komponenten sollte man nie Fehler dierekt anzeigen, also bleiben da nur
* Exceptions
* Boolean-Result und interner Statusspeicher ala GetLastError
* oder Fehlercodes
Und Fehlercodes, also quasi MagicNumbers findet ich etwas blöd, darum habe ich mich für Exceptions entschieden.
Sind die Exceptions aber lokalisierbar (ResourceStrings oder sonstwie), dann sollte die Exceptionklasse auch statische Fehlerinfos beinhalten (z.B. immer englischer Text oder Fehlercode).