try/catch - warum wird throw new Error() nicht ausgeführt und ist das die richtige Art, zurückzugeben was genau falsch ist?

[Rolf B]

Hallo ebody,

Der Gedanke war, dass jede Methode immer ein Objekt mit den gleichen Keys zurückgibt

Ich bezweifle, dass die Wiederverwendung einer Eigenschaft für unterschiedliche Zwecke sinnvoll ist. Letztlich ist es aber deine Entscheidung.

Zum Thema "Verlust des Bezugs": Das arrCheck-Array, das die Prüfobjekte enthält, steht nach der Rückkehr aus der Methode für sich. Du musst für die „Berichterstattung“ die Bezug zu den Parametern rekonstruieren. Besser ist es, wenn arrCheck diesen Bezug enthält. Wie auch immer man das möglichst leichtgewichtig realisiert; du möchtest ja nicht für jeden Methodenaufruf eine monumentale Datenstruktur mit Prüfergebnissen aufbauen. Im Gegensatz zum parameter-Objekt, wo Deine check-Methoden sitzen, wird arrCheck ja wirklich für jeden Aufruf gebildet.

Im parameter-Objekt ist es dagegen wurscht, ob Du eine oder 100 Methoden einbaust. Die Verteilung der Tests auf mehrere Methoden hat aber deshalb Laufzeitvorteile, weil switch - im Gegensatz zur switch-Implementierung beispielsweise in C oder C++ - von oben nach unten prüft. X Cases ergeben durchschnittlich X/2 Abfragen pro check-Aufruf. Das Auffinden einer Methode im Methodenverzeichnis eines Objekts erfolgt dagegen über einen Hash und gelingt deshalb mehr oder weniger zeitverlustfrei. Das ist aber nicht der Hauptgrund für eine Aufteilung. Sondern: (a) ist es weniger fehleranfällig, weil ein vertippter Methodenname im Log sofort auffällt und (b) sind viele kleine Methoden besser lesbar als eine große.

Wenn ich über response in einem Fehlerfall das Objekt erhalte, zeigen die Keys, um welche Prüfung es ging.

Aha. Soso. Und dann verwendest Du in der status-Methode Object.values(obj) und guckst Dir die Keys gar nicht erst an.

Es ist auch irrelevant für die Fehlerberichterstattung. Aber wenn Du unbedingt willst, hänge den Namen der Prüfung in das Objekt, das von der Prüfmethode zurückgeliefert wird. So, wie Du es jetzt machst, musst Du den Prüftyp zweimal hinschreiben - einmal als Key im Objekt und einmal als Parameter der check-Methode.

Jetzt, wo ich mir das ein paarmal durch den Kopf habe gehen lassen - Du könntest auch mit Prototypen arbeiten. Wenn Du N Prüfungen hast, gibt es - so wie es jetzt gebaut ist - genau 2N mögliche Ergebnisobjekte, denn der Namen des geprüften Parameters steht ja gar nicht drin. Statt diese Objekte bei jeder Prüfung neu zu generieren, kannst Du sie einmalig erzeugen und dann für das eigentliche Ergebnis als Prototyp verwenden. Das reduziert den Aufwand für die Ergebniserzeugung deutlich; die meiste Arbeit findet nur einmal statt, bei der Erzeugung des parameter-Objekts.

https://jsfiddle.net/Rolf_b/py3ajsu8/

Nur mal so als Idee. Das Fiddle arbeitet gnadenlos funktional, mit Closures, Prototypen und selbstdefinierten Properties. Kann man mit class-Syntax vermutlich nochmal verschönern.

Rolf