Falsche Parametertypen

[Sophie]

Hallo Rolf,

Solange alles mein eigener Code ist, würde ich falsche Parametertypen durch Unit-Tests entdecken wollen. Steckst Du in eine Funktion falsche Typen hinein, dürften die Unit-Tests vor die Pumpe fahren.

Ich habe mich gerade ein wenig in Unit-Tests eingelesen und bin dabei unter anderem auf QUnit gestoßen. Aber ich verstehe nicht, wie ich „falsche Parametertypen [damit] entdecken [sollte]“. QUnit ist doch dazu gedacht Codeabschnitte (Funktionen, Units) auf ein erwartetes Ergebnis zu prüfen. So interessant ich Unit-Test auch finde (kannte ich bis gerade eben nicht), ich denke nicht, dass sie mich auf meine Frage hin weiterbringen, oder? Und wie definierst du „mein eigener Code“? »Private Variablen, Funktionen und Sowas«, »Code, den eh kein Anderer zu Gesicht bekommt«, ... ?

Wenn Du eine Bibliothek schreibst, sieht die Sache natürlich anders aus. Da können Prüfungen in der öffentlichen Schnittstelle durchaus sinnvoll sein. Wenn Du mit dem falschen Typ nicht weitermachen kannst, solltest Du auch eine Exception werfen. Es ist ja schließlich ein Programmierfehler, da darf es gerne laut scheppern.

Ich denke das ist der Punkt, zu erkennen wann man mit einem falschen Typ nicht weitermachen kann.
Angenommen meine Funktion erwartet einen Parameter vom Typ Number und ich prüfe mit typeof und jemand kommt ernsthaft auf die Idee new Number(10) als Parameter zu übergeben. Kann mir das egal sein (--> TypeError werfen) und wirklich nur auf Primitives setzen?
Oder meine Funktion erwartet einen Parameter vom Typ Number und jemand übergibt einen String der a) nur eine Zahl enthält ('42') oder b) eine Zahl am Anfang hat und Nicht-Ziffern danach ('42foo') oder c) (am Anfang) nur aus Nicht-Ziffern besteht ('foo42', 'foo'). Ich könnte nun versuchen, den String mit Number() oder window.parseInt() nach Number umzuwandeln und mit window.isNaN() schauen, ob ich nach der Umwandlung immer noch Mist habe, aber wo endet die Toleranzgrenze?

Aber man sollte schon selber prüfen und ein TypeError werfen, wenn was nicht stimmt, anstatt stur zu versuchen seine Funktion abzuarbeiten und möglicherweise ein automatisches TypeError in der Konsole zu produzieren, oder?

Mal nebenbei: Mache ich mir einfach zu viele Gedanken über solche „Kleinigkeiten“ oder darf ich wegen der positiven Bewertung davon ausgehen, dass mein Problem doch gar nicht so doof ist? Gut, doof ist es schon, denn mir zumindest geht es ziemlich auf die Nerven. Ihr wisst schon, wie das gemeint ist...

Da "==" dazu gemacht ist, eine type coercion anzustoßen, und "===" das nicht tut, kann man davon ausgehen, dass "===" eine Spur fixer ist.

Okay, danke.

Liebe Grüße,
Sophie